GitHub星数最高的开源Agent，本地部署成功率却垫底？_服务软件

1. 工具永远是工具，驱动创新的永远是人类的想象。 #大咖观察 #红衣聊AI #人工智能 #科技改变生活 #AI工具

2. 从失败中学习，榨干经验包，实现性能飞跃 ——Google Agent研究

3. 【那些让你惊叹的AI Agent，99%都是假的】最近Google放出了一份64页的内部技术手册，直接戳破了AI Agent领域最大的泡沫。当整个科技圈都在吹捧“自主AI员工”的时候，真相是：你上周看到的那个创业公司演示的Agent，本质上就是几个API调用加上漂亮的提示词。这根本不是Agent，只是昂贵的ChatGPT外壳。Google提出了一个新概念叫“AgentOps”，类似于机器学习领域的MLOps，但专门针对Agent。包括评估框架、监控面板、CI/CD流水线、基础设施配置。和“拼几个提示词就上线”完全是两个世界。真正的Agent需要通过四层评估检验：第一层是组件检查，看它是否每次都能调用正确的API。第二层是逻辑检查，看你能否追溯它的推理过程。第三层是质量检查，看输出结果是否真的有效。第四层是安全检查，看它能否被越狱攻击。现实是，大多数Agent连第一层都过不了。安全问题更值得警惕。当你给Agent数据库访问权限时，你实际上是把整个公司的钥匙交给了它。提示词注入、数据泄露、静默失败，这些风险被大多数团队当作事后才考虑的问题。演示和生产环境的差距是巨大的。演示在沙盒里运行，输入完美可控。生产环境面对的是边缘情况、愤怒的用户、凌晨三点宕机的系统。那个在圈内传开的47000美元失控循环事故就是血淋淋的教训。Token爆炸、静默递归、零监控，这就是没有监控就部署的代价。演示优化的是惊艳效果，生产优化的是可靠性。这两者之间隔着一条鸿沟。Google押注的是基础设施，而不是噱头。当创业公司还在烧钱做Agent玩具的时候，Google正在铺设所有人最终都需要的轨道。如果你在构建Agent时没有评估框架、没有监控、没有可靠性设计模式，那你构建的就不是Agent。Agent经济不会真正到来，直到我们停止把这件事当作提示词工程来对待。最先想明白这一点的公司，将主导下一个十年。x.com/rryssf_/status/2015742275607998481

4. 如何解决Cursor等Agent编码开发轮次多了过后代码库变成屎山的问题？

5. 打造13个Claude Agent 互相 review 彼此↓ Reddit 一个开发者用 OpenClaw 框架搭建了 13 个 Claude Agent，让它们像真实团队一样工作：有人写代码，有人 review，有人测试，有人查安全漏洞。然后还互相 review 彼此的工作。 1 Writer Agent → 生成代码 2 Reviewer Agent → 逐行审查，对标 code review 标准 3 Tester Agent → 设计测试用例，验证逻辑 4 SecurityAuditor Agent → 扫描安全漏洞 5 Optimizer Agent → 性能优化建议 6 DocumentWriter Agent → 生成 API 文档 7 QA Agent → 最后一关，综合检查 ... + 6 个其他专业角色 vs. 链式流程（A→B→C），这个设计采用质量门控流程。Reviewer 必须 approve 才能进入下一阶段。出问题时反馈重做。成本控制？看起来 13 个 Agent 全力跑，tokens 肯定爆炸。但这个哥们用了几个聪明的招： 1. Context 优化 Writer 不需要看 test cases，Tester 不需要看文档。每个 Agent 只加载相关上下文。这一招可以干掉 80% 冗余 token。 2. 采样策略不是每一行代码都通过全部 13 个 Agent。核心路径 100% 检查，非关键路径采样。 3. 缓存和复用已审查过的代码片段不重复审查。测试用例库复用。架构决策缓存。结果呢？ - 单个开发者 Claude Code：每天 5-20刀 - 13 个 Agent 团队：每天 15-30刀（成本增加不多，质量翻倍）实际对比维护 10 万行代码库： 1. 传统手工做法 - 人工 code review：8 小时 - token：50-80刀 - bug 漏过率：5-10% 2. 13 个 Agent 团队 - 总耗时：30 分钟（Architect 规划 → Writer 并行生成 → Reviewer 自动审查 → 全流程质量门控） - token：20-25刀 - bug 漏过率：<1% 为什么这个方案特别？ 1. 角色化 > 能力化不是「给 Claude 一个超级 Prompt 让它什么都会」，而是「给每个 Agent 一个明确的职责」。 Writer Prompt：「你是代码作者，你的工作是...」 Reviewer Prompt：「你是资深 code reviewer，标准是...」角色专业化自动带来质量提升。 2. 质量门控自动化传统 code review 是人工 bottleneck。Agent review 是自动化 + 可扩展的。 3. 知识积累每个 Agent 的执行历史（什么被 reject、为什么）可以持续优化 Prompt。这是机器学习意义上的反馈循环。 4. 工程意义这不是「用 AI 替代人」，而是「用 AI 团队协作替代个人英雄主义」。更接近真实团队的工作方式。背后的思想转变从「Prompt Engineering」→ 「Architecture Engineering」以前我们花时间优化单个 Prompt，试图让一个 AI 更聪明。现在聪明的做法是设计系统，让多个 AI 通过角色分工和质量门控，集体产出更高质量的结果。原文：www.reddit.com/r/ClaudeAI/comments/1rga7f5/how_i_built_a_13agent_claude_team_where_agents/ #how i ai##程序员#

6. 【别搞错了，生产级AI Agent的核心根本不是AI，而是分布式系统】快速导读：大多数人以为构建Agent就是“Prompt+工具”的循环，这是一种危险的误解。一旦涉及真实用户、高并发和容错，Agent就从一个AI问题，变成了经典的分布式系统工程问题。这解释了为什么大量Agent项目最终都只是个玩具。 --- 很多人觉得，构建AI Agent无非就是把Prompt和工具扔进一个循环里。这个假设很合理，但它根本就不是生产环境的架构。你的Agent一旦需要知道自己在跟谁说话、需要保持状态、处理并发请求、执行敏感操作，以及在工具调用失败后幸存下来——它就不再是一个“LLM+工具”的简单组合，而蜕变成了一个不折不扣的分布式系统。构建Agent本身是简单部分，市面上有无数框架帮你搞定。真正的难点在于“运行时”——那个包裹着Agent、让它能在真实世界里可靠工作的系统。这才是所谓的“智能体软件工程（Agentic Software Engineering）”。构建Agent是AI工程，但在生产中运行它是软件工程。这套工程体系由六根支柱撑起：持久性、隔离性、治理、状态、扩展性和可组合性。每一个都指向经典的分布式系统难题，比如数据隔离失败就是数据泄露，而服务过载则意味着你继承了所有第三方API的速率限制和延迟。这解释了为什么那么多Agent项目最终都像个漂亮的玩具，却无法成为可靠的产品。AI行业还没有完全吸取过去几十年我们在构建可靠分布式系统中学到的教训。最终，能把这套软件工程的纪律内化到团队血液里的，会交付出伟大的产品。而那些继续把Agent当作脚本对待的，会继续与成功失之交臂。 --- 简评：一针见血。AI圈的热潮让很多人忘了，再聪明的“大脑”也需要一个强壮的“身体”才能在现实世界里行动。这篇文章把焦点从算法和模型，拉回到了决定产品生死的工程纪律上。当你的Agent需要审批、回滚、保证用户数据隔离时，你面对的就不是一个AI问题，而是对你软件工程成熟度的拷问。 --- ref: x.com/ashpreetbedi/status/2028176285575594465 #AI创造营##人工智能#

7. 2026年AI全景预测：迈向百亿智能体时代的20个发展趋势。 #大咖观察 #人工智能 #红衣聊AI #智能体 #AI时代

8. 如果你现在还没用Agent帮自己干活，那其实很危险

9. 豆包大模型 1.8 发布，通用 Agent 模型成为了 AI 行业的新叙事

10. PAI（Personal AI Infrastructure）：给 AI Agent 装上持久记忆 Daniel Miessler 开源的 PAI，核心是把 Claude Code 改造成一个能持续进化的个人 Agent。关键在记忆系统。普通 AI 每次对话都从零开始，PAI 会记住： 1. 你的目标和偏好 2. 历次决策的过程和结果 3. 哪些方法有效、哪些踩过坑 4. 你对输出的评分和反馈设计上三个关键点： 1. Agent 的价值上限取决于记忆质量——每次交互都是训练数据 2. hook 系统是关键：在工具调用层面捕获信号，比对话层面更准确 3. 个人 AI 基础设施的竞争点不是模型，是上下文积累的深度整个工作循环：观察 → 思考 → 规划 → 执行 → 验证 → 学习 → 改进。每跑一次，Agent 对你的理解就深一点。实现方式不复杂：在 Claude Code 上加一层 hook 系统，每次工具调用前后自动捕获信号，沉淀进 MEMORY 目录。跨会话持久存储，下次启动直接读取上下文。大多数人现在搭 personal agent 的方式是手动维护一个 MEMORY.md，PAI 做的事是把这套流程系统化：自动写入、自动分层、自动迭代。项目：github.com/danielmiessler/Personal_AI_Infrastructure #HOW I AI# #程序员#

11. 【Codex Subagents：136个AI专业分身让编程效率起飞】快速阅读：一个开源项目收录了136个针对Codex的专业化AI助手，覆盖从前端开发到安全审计的各个领域。每个Agent都有独立的上下文窗口和专门指令，能像真实团队成员一样处理特定任务。关键是这些Agent不会自动触发，需要明确指派。—AI编程助手的进化方向可能不是更强的单一模型，而是一群各司其职的专家。这个叫awesome-codex-subagents的GitHub仓库里，藏着136个经过精心调教的AI分身。前端有React专家，后端有Go并发高手，安全审计、性能优化、数据库调优，甚至Active Directory管理都有对应的Agent。每个Agent都是一个.toml配置文件，指定模型、沙盒权限和专业指令。比如security-auditor用gpt-5.4处理深度推理任务，search-specialist用更快的gpt-5.3-codex-spark做信息检索。审查类Agent设为只读权限，开发类Agent可以修改代码。这种设计既保证专业性，又控制权限范围。GitHub: github.com/VoltAgent/awesome-codex-subagents#AI创造营##人工智能#

12. Claude Code subagent vs.Agent Teams vs. worktreeClaude Code支持多Agent协作，但里面的sugagent、Agent Teams、git worktree 概念容易混淆，好像都能并行协作开发。大多数开发者的错误做法是：把所有多Agent任务都用Agent Teams，或者把简单的工作也劲头十足地搞worktree，结果代码复杂度爆炸。1. Claude Code官方文档现在把它分成三个清晰的层级：层级1：Subagent（会话内辅助）适用场景：在当前编码会话内部创建临时任务特点：轻量级、快速、无需通信开销例子：「帮我写单元测试」「重构这个函数」「生成API文档」本质：一个主Agent指挥多个临时小助手，完成当前任务成本：低，通信延迟小层级2：Agent Teams（需要Agent间通信的并行任务）适用场景：多个Agent需要真正协作、信息交互特点：Agent有各自的记忆、上下文、角色定位例子：前端Agent + 后端Agent + DevOps Agent 协同开发一个微服务架构本质：真正的「团队」，每个Agent有独立决策权成本：高，需要复杂的通信协议和状态管理层级3：Git Worktree（轻量并行选项）适用场景：传统多分支开发，手动协调特点：完全依靠Git，不需要Agent间通信例子：同时开发feature1和feature2，用两个worktree分离代码树本质：操作系统级别的并行，Agent各自独立运行成本：中等，但需要手动协调merge2. 实战建议：1）刚开始用Claude Code？用Subagent。让一个主Agent指挥，足够了。2）小团队开发微服务？用Agent Teams，但不要超过3个Agent（通信成本会爆炸）。3）大型项目长期并行？用Worktree，保持简单，让人类开发者协调。大多数人的错误是高估了自己的需求，直接跳到Agent Teams。结果是Agent间通信变成性能瓶颈，不如一个聪明的Subagent快。3. 背后的工程思想这个三层设计反映了一个深层原则：越高级的能力，越要谨慎使用。Subagent看似简单（一个主Agent内部）但足以解决90%的任务。Agent Teams强大但需要精细的通信协议。Worktree原始但极其稳定。官方的建议其实是在说：从最简单的方案开始，只在确实需要的时候才升级。这叫做「渐进式能力提升」。很多开发者喜欢一上来就用最强的功能，结果代码难以维护、Agent间延迟高、调试成本爆表。明确边界后，选择变得简单了。官方文档：code.claude.com/docs/en/agent-teams#HOW I AI# #程序员#

13. 🚨突发新闻：Qwen 团队刚刚发布了他们的官方代理框架，它包含了所有功能。无需拼接第三方库。无需对抗抽象概念。Qwen-Agent 为您提供：→框架内直接内置的原生函数调用→开箱即用的安全代码解释器沙箱→ RAG 和 MCP 支持包括→用于浏览器原生代理工作流程的 Chrome 扩展程序由构建模型的团队开发，所以它运行稳定可靠。100% 开源且完全免费。

14. 在线开发智能代理系统遇到上下文管理难题？推荐看看 muratcankoylan 的开源项目「Agent Skills for Context Engineering」，这是一个面向生产级 AI 代理系统的全面技能库。它提供了完整的上下文工程方案，涵盖基础理解、架构设计、多代理协作、工具开发、评估优化等多维度技能，帮助你科学管理语言模型的上下文窗，实现最高效的上下文利用和智能决策。主要亮点：- 深入讲解上下文衰减、压缩和优化，避免模型“迷失中间”；- 支持多代理架构设计，含监督者模式、图谱记忆、沙盒环境等；- 提供完善的评估框架，支持LLM作为裁判进行性能对比和偏差缓解；- 包含项目开发全流程指导，从概念设计到流水线部署；- 独家认知架构技能，形式化建模代理心智状态，实现理性推理与解释；- 跨平台、通用原则，适配Claude Code、Cursor等主流代理平台。GitHub：github.com/muratcankoylan/Agent-Skills-for-Context-Engineering无论你是搭建单一代理还是多智能体系统，这套技能库都能助你构建、优化和调试高效智能体，推荐 AI 开发者和研究者深入学习！#AI创造营##人工智能#

15. 一个视频带你快速盘点2025年GitHub热点项目

16. 养个电商🦞团队，让它们自主开店、谈客户

17. 《走近科学》——多Agent不是万能药，从玄学走向科学，来自Google和MIT的研究

18. Agency Agents：号称能一键搭建一个“AI公司”，配备55个高度专业化的AI员工，涵盖了工程、设计、营销、产品、项目管理、测试、支持、空间计算等多个部门，非常像现实中的公司架构。项目亮点：- 明确分工，每个AI都是某个领域的大咖，比如前端工程师、品牌守护者、增长黑客、Sprint优先级规划师、质量验证专家等；- 强调协作和流程，模拟真实团队工作，解决单一大模型扛全的性能瓶颈和职责模糊问题；- 支持Claude Code等主流AI代码工具，且自带批量生成和安装脚本，方便集成到各种AI开发环境。社区反馈和潜在问题：- 很多网友表示这套系统在“演出”层面非常完整和有趣，但实质执行时仍然有上下文共享难题，多个agent之间的记忆和协调尚不可控；- 多agent间消息传递带来海量tokens消耗，成本和效率成了大考验；- 也有人提出可以配合类似GSD，Paperclip等工具做更好地执行管理和成本控制；- 有人建议加入一个“成本管控agent”，专门监控预算和token消耗，避免“爆账”。未来展望：这类多agent“AI公司”架构是2025年后业界的新趋势，有论文表明多agent协作能提升复杂任务完成率25%左右，远优于单agent模型。尽管目前还处于早期，可玩性和探索价值极高。正如Greg所说，未来属于愿意折腾这些新技术的创造者。想玩转AI多agent团队，又想少踩坑的话，这个项目值得关注和研究。源码开放，社区活跃，非常适合爱折腾的工程师和创始人们自己动手搭建“未来的公司”。#AI创造营##人工智能# GitHub：github.com/msitarzewski/agency-agents

19. Agent 框架记忆问题的解法～用过 LangChain、CrewAI 这些 Agent 框架的都知道一个痛点：它们的记忆管理很鸡肋。大多数框架的做法是：短期放在列表里，长期靠 RAG 检索。听起来合理，实际很脆弱。问题在哪？1. 信息丢失。RAG 只会检索出片段，但对话的整体脉络、为什么重要、前后的因果关系都丢了。用户说"上次那个项目"，Agent 可能查出相关文档，但根本不知道用户为什么关心这个项目。2. 幻觉加倍。Agent 基于零碎的检索结果推理，没有全局认知，自然容易编造细节。3. 记忆冲突。同一件事在不同时间表述可能不一样，Agent 也不知道哪个才是"真相"，结果前后矛盾。核心问题：RAG 本质是"我记不全，就检索部分"——但这对需要全局一致性的 Agent 任务来说，根本不够。文章的解法：混合记忆架构，不是非此即彼，而是分层：第一层：实时记忆 —— 最近 N 轮对话完整保留，一个字都不丢。这保证了 Agent 对当前对话的理解是准确的。第二层：压缩记忆 —— 更早的对话不是直接存，而是压缩成摘要。比如 50 轮对话压缩成"5 个关键决定 + 3 个重要背景"。成本低，还保留了信息密度。第三层：语义检索 —— 用向量数据库索引压缩后的记忆。这样检索时找的是"高浓度摘要"，而不是淹没在海量文档里。第四层：验证 —— 最关键的一步。Agent 每次从记忆里检索出来东西，要自己验证一下："这个旧记忆和我现在的对话一致吗？"不盲目信任。为什么这个方案值得用？1. 解决了 RAG 的致命问题——记忆有连贯性，Agent 知道全局脉络，不再前后不一。2. 成本可控——压缩记忆大幅降低向量库规模和 token 消耗，相比把所有历史都存下来，省一个数量级的钱。3. 可验证——加验证层，Agent 不会死板地信任过期的记忆。适用场景：- 长期对话的 AI 助手（用户期望 Agent 真的"记得我们的历史"）- 复杂多轮谈判或诊断（需要一致决策，不能前后矛盾）- 需要积累知识的任务流不适用的场景：- 单轮或短对话（没必要这么复杂）- 纯知识库查询（RAG 本身够用）原文：dev.to/diego_falciola_02ab709202/every-ai-agent-framework-has-a-memory-problem-heres-how-i-fixed-mine-1ieo#HOW I AI# #程序员#

20. 3天赚1200刀？纯聊天就能捏出个能搞钱的 AI Agent！【教程】

21. 2025年被科技界提及最多的词—Agent！大家都把它视为下一个风口。那究竟什么是Agent？Agent到底能做些什么？这期视频，带大家看看理想同学Agent又能带给我们的生活哪些改变？ #理想i8# 骆智慧的微博视频抽奖详情

22. AI原生电商出现，Agent帮你从建站到运营

23. Agent Skill 相关资料、笔记和思考

24. 突破一亿Token极限：EverMind提出MSA架构，实现大模型高效端到端长时记忆

25. Anthropic发布万字长文：系统化评估 AI Agents 的工程方法

26. 如果人还需要刻意的去区分Script（脚本）、Skills、Agent，说明 Agent 还不够聪明。理想情况下，任何要求都只需要跟 Agent 说，如果一个要求 Agent 被要求处理很多次，它应该结合历史记忆，主动把这个要求自己整理成 Skills，Script 则是 Skills 的一部分。并且这些 Skills 它是持续更新维护的。所以我现在是什么事都跟 Agent 说，但是我会在执行任务后，引导它去写 Skills 或者更新 Skills

27. vibe coding时代，Agent写代码的空档，你在做什么？

28. #OpenClaw是什么#一次看懂OpenClaw是怎么自动干活的。 OpenClaw 在中国的发酵速度，远超美国人想象。中国大厂的动作真的太快了，比美国云厂商快得多。阿里、腾讯、字节三家都把OpenClaw搬上了各自的云平台，但美国这边，亚马逊、微软、谷歌云，一家都还没动。但是，晚晚我估计不是美国大厂不想做，大概率是中国大厂反应快，卷得快。腾讯云上跑OpenClaw，一年只要10到76美元，可以直接接DeepSeek，通过钉钉、QQ、飞书来操控AI Agent。百度更激进，直接把OpenClaw嵌进搜索App。中国开发者的改造速度真的叹为观止一鸣惊人。据说所有AI公司，过年基本就没有休息的。晚晚还观察到一个结构性差异，觉得很有意思。硅谷OpenClaw发展，是自下而上。个人开发者先发现好玩，GitHub 星星爆了，口碑往上传，公司才跟进。中国刚好反过来。大厂先接，平台打包好，价格压低，开发者拿来直接用。是自上而下的渗透，从基础设施层开始铺。美国靠个体创新往上冒，中国靠平台整合往下渗。某种程度上， OpenClaw扩散的方式，复刻了各自社会的运作逻辑，复刻了各自政治文化DNA。是不是很有意思。#从小学生到工程师都在装OpenClaw# http://t.cn/AXV4JDO8

29. 空降OpenAI 智能体榜单第一名的FM Agent什么来头，有哪些信息值得关注？

30. 上个月，谷歌悄然发布了五篇关于AI Agent的重磅论文，连续五天每天一篇，深入探讨了Agent的构建、评估、安全和部署等核心问题。没有大张旗鼓，250多页的技术细节静静铺开，值得每个AI从业者认真研读。这五篇论文的核心内容总结如下：1. 什么是Agent？谷歌重新定义了Agent，强调它们能力的演进和为何大多数Agent一离开演示环境就崩盘。现有Agent更像是复杂的工作流和工具编排，而非真正的自主系统。kaggle.com/whitepaper-introduction-to-agents2. 工具和MCP（多能力协议） MCP允许服务器无须用户同意即添加工具，虽然增强了能力，但也带来边界风险。换句话说，Agent仍然无法“感知”世界，只是更有效地调用API。kaggle.com/whitepaper-agent-tools-and-interoperability-with-mcp3. 记忆问题真正的记忆不是简单的上下文窗口、检索增强生成（RAG）或向量存储，而是一个动态、结构化的长期记忆，影响未来推理和行为。谷歌提出了会话拼接和动态上下文窗口，但本质差距依然存在。kaggle.com/whitepaper-context-engineering-sessions-and-memory4. Agent质量评估评价不仅是输出正确与否，更重视Agent的推理过程。论文提出了正确性、鲁棒性、重复性、多步稳定性和幻觉控制等指标，揭示当前架构在这些方面的脆弱。kaggle.com/whitepaper-agent-quality5. 从原型到生产构建Agent简单，信任它完成真实任务困难。论文详细说明了沙盒环境、安全护栏、评估循环和人工干预机制，反映出系统的不确定性和脆弱，需要大量安全网。kaggle.com/whitepaper-prototype-to-production深度思考：谷歌的努力展现了巨大的工程投入，但他们依然被“语言模型物理学”所限制。试图通过不断修补LLM来实现真正的Agent，是在用“token机”伪装认知。真正的自治智能需要内在的组织、自我预测、力量感知和发展结构，而这些是现有LLM架构根本不具备的。这五篇论文不仅是技术文档，更是行业缺失的蓝图。它们提醒我们，构建Agent不仅是搭建工具链，更是要建立能够自我调整、自我稳定的认知架构。谷歌在工程上走得很远，但未来的Agent革命还在于基础架构的重塑。x.com/techNmak/status

31. 从失败中重生：一个 AI Agent 前端落地的真实复盘同步发布于博客：网页链接今天在 FEDay 上分享了一个 Agent 前端落地案例，核心内容是讲述了我参与的一个团队如何从"技术成功"走向"产品失败"，又如何在复盘中获得认知升级。这个故事的价值不在于成功的方法论，而在于那些踩过的坑和思维转变的过程。2025 年被称为 Agent 元年。Deep Research、Manus、Claude Code 相继发布，技术圈一片沸腾。很多团队都在问同一个问题：我们要不要做 Agent？在开始之前，我还是想讲一下我对 AI Agent 的定义：AI Agent（AI 智能体），是为了实现某个目标，循环调用工具的大语言模型。- 工具循环（tools in a loop）：模型调用工具 → 获取结果 → 继续推理- 有明确终点：为了达成目标，而不是无限循环- 目标来源灵活：可以来自用户，也可以来自另一个 LLM- 基础记忆能力：通过对话历史保存上下文信息朋友负责的团队面临的是一个真实的企业痛点：公司有完整的内部设计系统（Design System）和私有前端框架，但这些代码从未被 AI 训练过，通用模型根本无法直接生成符合规范的代码。目标看起来很清晰——做一个类似 Lovable 的工具，但用的是自己的 Design System。用户上传 Figma 设计稿或截图，Agent 自动生成符合内部规范的前端代码。听起来很美好，对吧？但挑战也很现实：- 要完整搭建一个 Agent 系统没想的那么容易，不仅要和模型交互，还要处理好用户交互，还有上下文工程- 要让模型理解和使用从未训练过的私有组件- 要在浏览器中实时预览生成结果- 出错了希望能自动修复由于团队之前没有开发过 Agent 相关产品，所以请我参与其中，提供技术咨询和方案建议。我第一个建议很现实：先跑通再优化—— 构建 Agent 最难的不是技术，而是完整跑通流程。我推荐他们基于 Claude Agent SDK 进行二次开发，而不是从零造轮子。一些关键理由包括：1. Claude Code 已经验证了它是可行的2. 开箱即用，内置工具足够满足绝大数场景3. 可以自定义工具、接入 MCP、自定义 Skill4. 可以接入国产兼容模型还帮着基于 Claude Agent SDK 快速搭建了一个原型系统。一些关键代码还开源在这里：网页链接这样很快有了个基本可用的 Agent。接下来就是解决代码的浏览器预览问题。一开始我们尝试用 Sandpack（浏览器端沙盒）做代码预览，结果发现复杂组件根本跑不起来，而且无法发挥 Agent 读写文件的能力。转向方案是给 Agent 一个本地文件系统——每个会话一个独立环境（虚拟机或目录），Agent 可以自由读取、修改、编译代码。这个决策让 Agent 的能力得到了最大化发挥。给 Agent 一个本地文件系统才能最大化的发挥 Agent 能力给 Agent 一个本地文件系统才能最大化的发挥 Agent 能力另一个难题就是如何让 AI 学会使用从未训练过的私有组件？其实就是把 Agent 当作新员工，用高质量文档和参考代码来教会它。我们把设计系统说明、组件列表、API 文档全部 Markdown 化，让 Agent 按需检索。高质量的参考代码本身就是最好的教材。而且完全不需要复杂的 RAG 系统，直接让 Agent 去基于文件检索搜索本地文档和代码就足够了。还有一个难题就是如何保证生成代码的质量，让代码能跑起来？为了保证代码质量，为 Agent 建立了一套"生成 → 验证 → 修复"的自动化闭环：Lint 静态检查、编译验证、视觉比对（借助 Chrome DevTool MCP 做截图对比）。一个节约主 Agent 上下文的技巧：把验证工具放入 Skill 或 SubAgent，避免污染主 Agent 的上下文。把这些问题都解决后，Agent 终于上线了。系统跑通了，Demo 很惊艳，但……很快就没什么人用。初期大家觉得新鲜，但很快就弃用了。开始和他们一起深度复盘，发现问题根本不在技术，而在产品逻辑与用户习惯的错位。通过对内部员工的调查访谈，很快就找到了原因：习惯阻力：设计师和产品经理更习惯在 Figma 里工作，而不是对着一个对话框。从舒适区（Figma）跳到陌生区（Agent 对话），这个门槛比想象中高得多。大部分甚至不知道该在聊天窗口写啥。80/20 瓶颈：Agent 能实现 80% 的效果，但剩下 20% 的修改成本极高。而往往就是那 20% 决定了能不能用。流程割裂：生成环境和开发环境是脱节的，无法利用现有代码，需要手动把生成的代码复制回项目，操作繁琐。团队意识到，他们最初问的问题是："如何构建一个设计系统 AI Agent？"这种提问方式让 Agent 变成了目的本身，为了技术而忽略了本质。正确的问题应该是："我们设计系统的最终目的是什么？"答案其实只有两点：在整个企业内实现设计规范的统一；实现开发效率的提升。设计系统只是手段，而非目的。思维转换：以 AI 为中心重新设计现有的流程是为人设计的：手动沟通、反复修改、人工确认，步骤繁杂，效率低下。未来的流程应该为 AI 设计：Input → AI Agent → Output，路径直接，效率高。这带来了两个新的设计原则：AI 友好：选择 AI 容易理解和操作的技术栈。轻量化：只保留 Design Tokens，基于 AI 友好的开源系统（如 shadcn/ui）进行扩展，而不是维护一套庞大的私有组件库。破局之道：从 Agent 到 Skill最关键的转变是：不要做一个独立的 Agent 平台，而是将能力嵌入现有的 AI 开发环境。旧模式是"独立 Agent 孤岛"——Agent 和开发者之间存在割裂，效率低下。新模式是"融入开发工作流"——把设计系统变成一种 Skill（技能），可以被通用的 Agent（如 Claude Code、Cursor）调用。Skill 的具体形态很简单：Markdown 文档（供 AI 查阅组件用法）+ 自动化脚本（用于初始化项目、自动安装和应用设计系统）。开发者在自己熟悉的 AI 开发环境里工作，当需要用到设计系统时，Agent 自动调用这个 Skill，生成的代码直接进入项目代码库。Skill 的具体形态很简单：Markdown 文档（供 AI 查阅组件用法）+ 自动化脚本（用于初始化项目、自动安装和应用设计系统）。开发者在自己熟悉的 AI 开发环境里工作，当需要用到设计系统时，Agent 自动调用这个 Skill，生成的代码直接进入项目代码库。可以参考：网页链接这个案例让我想到几个更深层的问题：1. 技术成功 ≠ 产品成功很多技术人（包括我自己）容易陷入"技术可行就是成功"的思维定式。但用户不会因为你的技术牛就买单，他们只关心能不能解决自己的问题、能不能无缝融入自己的工作流。2. 做 AI 产品要"以 AI 为中心"思考我们常说"以用户为中心"，但在 AI 时代，可能需要增加一层：以 AI 为中心设计工作流，再让用户享受这个高效流程的成果。不是让 AI 模仿人的工作方式，而是重新设计工作方式让 AI 更高效。3. Skill > Agent独立的 Agent 平台有天然的adoption障碍。把能力封装成 Skill，嵌入已有的通用 Agent 生态，可能是更务实的落地路径。这也是为什么 Anthropic 推出 web-artifacts-builder 这样的开源项目——它就是一个 Skill 的范例。4. 行动本身就是价值即使这个项目"失败"了，团队获得的认知升级是无价的。从模仿人类工作流到为 AI 重塑工作流，这种思维转变只有在实践中才能获得。最后我想说的是："去构建（Build）"。AI 时代，失败没什么，好过什么都没做。

32. OpenClaw狂揽16万star，是时候聊聊Agent Tools的AB面了

33. 推荐吕鹏（@甩甩鸟哥很严肃）开源的 Agmente 项目，让你可以从 iOS 手机上操作 Coding Agent Coding Agent。 OpenClaw 让我们看到了很多从手机指挥 Agent 的有趣场景，通过 Agmente 你可以在手机上跟 Gemini CLI、Claude Code、Qwen 等 AI 编程 Agent 对话，实时查看它们的工具调用和执行结果。吕鹏是 VS Code 团队的工程经理，主导了将 Copilot Coding Agent 和 GitHub Copilot CLI 集成到 VS Code 的工作，可以说他是最了解编辑器如何与 AI Agent 对接这件事的人之一。Agmente 最特别的地方在于它实现了 ACP（Agent Client Protocol，智能体客户端协议）——一个正在快速崛起的开放标准。ACP 要解决什么问题？现在 AI 编程 Agent 越来越多（Claude Code、Gemini CLI、Codex CLI……），编辑器/IDE 也很多（VS Code、Zed、JetBrains、Neovim……）。如果没有统一标准，每个编辑器想接入每个 Agent 都要单独写一套集成代码，反过来每个 Agent 想支持每个编辑器也一样。这就是经典的 M×N 问题。ACP 就是来解决这个问题的。它的角色类似于当年的 LSP（Language Server Protocol）——LSP 让任何编辑器都能接入任何语言的智能提示，ACP 则让任何编辑器都能接入任何 AI 编程 Agent。Agent 实现一次 ACP，就能在所有支持 ACP 的客户端上运行；客户端实现一次 ACP，就能接入整个 Agent 生态。从这个项目也反映出 AI Agent 发展中几个值得注意的趋势：1）Agent 正在脱离桌面束缚。以前编程 Agent 只能在 IDE 或终端里跑，Agmente 让你在手机上就能监控和交互。想象一下：你让 Claude Code 在远程服务器上干活，然后出门遛弯时在手机上查看进度、审批工具调用——这就是 Agmente 支持的场景。它通过 WebSocket 连接远程 Agent，还支持 Cloudflare Tunnel 做安全访问。2）标准协议正在改变游戏规则。就像 MCP 让 Agent 能统一访问各种工具和数据源一样，ACP 让 Agent 能统一接入各种客户端界面。一个 Agent 写一次 ACP 适配，就能同时在 VS Code、Zed、JetBrains、甚至手机上被使用，这大大降低了 Agent 生态的碎片化。3）从“人用编辑器”到“人监督 Agent”的范式转变。 Agmente 的交互设计很能说明问题——它重点展示的不是代码编辑界面，而是对话历史、工具调用和执行结果。这暗示了一种新的开发模式：开发者的角色从写代码变成下达指令、审核 Agent 的行为。项目地址：github.com/rebornix/agmente 网页链接

34. n8n要凉了？Agent Skills实测对比，谁才是AI自动化之王！

35. Agent 真正的护城河，正在从工具转向记忆资产

36. 实测扣子视频Agent，一句话量产爆款，适合起号的工具来了 #扣子Coze #AI #AIGC #智能体

37. 《从写代码到管 Agent，大多数工程师还没准备好》斯坦福首门 AI 软件开发课讲师 Mihail Eric 谈初级开发者的三重困境、多 Agent 编排的真正难点、Agent 友好代码库的标准，以及为什么初级工程师的'无知无畏'在 AI 时代反而是超能力。从写代码到管 Agent，大多数工程师还没准备好

38. 9个最佳的Claude Code提效项目1. Superpowers网页链接Superpowers是Claude Code的增强插件，提供快速原型开发和迭代编码能力。2. Awesome Claude Code网页链接精选的Claude Code资源、技巧、提示词、工具和集成的完整列表。3. GSD (Get Shit Done)网页链接轻量级任务自动化框架，帮助Claude Code高效完成日常开发工作流程。4. Claude Mem网页链接为Claude Code添加持久化内存能力，自动跨会话保存上下文，减少重复信息输入。5. UI UX Pro Max网页链接AI驱动的设计系统生成器，根据产品类型自动推荐配色、排版、布局和组件模式。6. n8n-MCP网页链接为Claude提供n8n自动化工作流的完整文档和API访问，让Claude能设计和部署复杂的自动化。7. Obsidian Skills网页链接Obsidian笔记软件的Agent Skills，使Claude Code能直接创建和编辑Markdown、Canvas和Bases。8. LightRAG网页链接轻量级检索增强生成框架，通过知识图谱和向量检索为Claude Code提供更精准的信息检索。9. Everything Claude Code网页链接production级Agent框架，包含28个专业子Agent、116个技能、59个命令和完整的安全审计系统。#HOW I AI# #程序员# （via. Hasan Toor)

39. Agent Skills 终极指南：入门、精通、预测网页链接“应该是全网最好的 Skills 中文指南与教程，全文 1.2w 字，包含了我对 Skills 的完整应用思考。巧借通用 Agent 内核，只靠 Skills 设计，就能低成本创造具有通用 AI 智能上限的垂直 Agent 应用。”内容包含： 1.最容易读懂的 Skills 概念与原理介绍 2.讨论 Skills 的真实价值、技术优势、对 AI 产品设计的影响 3.非常完整的 Skills 使用与开发教程 4.Skills 的场景识别，什么时候适合开发、使用 Skills？#AI创造营##科技先锋官#

40. AI Agent 很火，但 Agent Infra 准备好了吗？

41. 来了～NanoClaw：4000行代码的容器化 AI Agent Gavriel Cohen 用 Claude Code 开发，核心只有 4000 行。对比 OpenClaw 的 40 万行，设计理念完全不同： 1. 隔离方式 - OpenClaw：应用层限制，Agent 和所有接入服务在同一进程里 - NanoClaw：每个 Agent 跑独立容器，只能访问被授权的最小数据集举个例子：接了你飞书某个群，Agent 只能看这个群，其他消息完全隔离。 2. 代码量即安全边界 40 万行没人真正审计过。4000 行，你或者 AI 都能读懂架构和安全模型。 Karpathy 点评："装得进我脑子，也装得进 AI 的上下文——可管理、可审计、灵活。" 功能比 OpenClaw 少很多，还很早期，但安全模型更扎实。 🔑 三个关键点 ① 容器隔离比应用层规则可靠，权限最小化才是正确姿势 ② 代码量直接影响可审计性，越小越好理解 ③ Agent 安全问题才刚开始被认真对待 GitHub：github.com/qwibitai/nanoclaw #HOW I AI# #程序员#

42. Agentscope 之前还介绍过网页链接，强调易用性、可控性、模块化和多智能体协作能力。//@小黑和花花是傻狍子:有个agentscope sdk，他们百链平台可视化拖拽对应的sdk//@黄建同学:Qwen确实有一个Qwen-Agent，一个开发框架。开发者可基于本框架开发Agent应用，充分利用基于通义千问模型（Qwen）的指令遵循、工具使用、规划、记忆能力。访问：网页链接。//@是何老师吗:按Qwen的性格应该也会有类似的产品？

43. 这篇文章《Agent Design Is Still Hard》写的太好了，值得逐行细读！看完的6个感受：1. 如果你自己写 agent，建议尽量直接用底层 SDK（而不是高层抽象）；2. 明确缓存策略 — 尤其是对大模型 + 多步骤任务，非常关键；3. 引入强化机制（reinforcement）和 sub-agent / sub-inference，以提高 agent 的稳定性／可靠性；4. 如果你的 agent 会生成实际输出 (邮件、文件、报告等)，考虑用专门的 output tool，而不是把 “输出内容” 混在 agent loop 的消息里；5. 在设计共享状态 (shared state) 时，引入类似“虚拟文件系统 (virtual file system)”的机制，会让系统更模块化，也更适合复杂任务 + 多工具调用；6. 最难也是最重要的一点 —— 测试与评估 (testing & evals) 是 agent 系统工程中最棘手的问题，目前还没有通用／优雅的解决方案。原文转译如下：Agent 设计依然很难我觉得现在是时候写写我新学到的一些东西了。大部分内容与构建 agent 有关，少部分与使用 agent 式编程工具有关。总结：构建 agent 依然混乱。只要真正开始用工具，SDK 抽象就会崩。缓存如果你自己管会更好，但不同模型间差异很大。强化（reinforcement）比预期承担更多“驱动”任务，而失败必须严格隔离以避免把循环带偏。通过类似文件系统的共享状态是非常重要的基石。输出工具比想象中更棘手，模型选择依然强依赖任务类型。一、选择哪个 Agent SDK？当你构建自己的 agent，你可以选择直接使用 OpenAI SDK、Anthropic SDK 等底层 SDK，也可以选择更高层的抽象，例如 Vercel AI SDK 或 Pydantic。我们之前做的选择是采用 Vercel AI SDK，但只用其 provider 抽象，然后基本上自己驱动 agent loop。现在来看，我们不会再做这个选择。Vercel AI SDK 本身没有问题，但当你要真正构建 agent，会发生两个我们没预料到的事：第一，不同模型之间的差异大到不得不自己构建 agent 抽象。我们没发现任何 SDK 提供的抽象能真正匹配 agent 的需求。部分原因是：虽然 agent 的基础设计就只是一个 loop，但工具集不同会带来微妙差异。这些差异会影响抽象是否容易找到（比如缓存控制、不同的强化需求、工具提示、provider 侧工具等）。因为“正确抽象”现在还不清晰，所以使用平台的原生 SDK 让你掌控更多。而很多高层 SDK 要你构建在它们的抽象之上，最后这些抽象可能并不是你真正需要的。第二，当涉及 provider 侧工具时，我们发现使用 Vercel SDK 非常困难。消息格式尝试统一，但并不真正奏效。例如 Anthropic 的网页搜索工具会频繁破坏 Vercel SDK 的消息历史，我们至今还没完全搞清原因。此外，在 Anthropic 的情况下，缓存管理在其原生 SDK 中比在 Vercel 中容易得多，而且错误信息也更清晰。也许未来会变化，但至少现在，我们不会在构建 agent 时使用抽象层，除非整个生态已经稳定。对我们来说，目前抽象层的收益远远不足以抵消其成本。也许别人已经解决这个问题了。如果你看了觉得我错了，欢迎发邮件，我非常愿意学习。二、关于缓存的经验不同平台对缓存的处理方式非常不同。大家已经讨论过很多，例如 Anthropic 的缓存是收费的，并且需要你显式管理缓存点，这会从 agent 工程角度完全改变你的交互方式。一开始我觉得手动管理缓存很蠢：为什么平台不自动管理？但现在我完全反过来了，非常喜欢显式管理缓存。它让成本与缓存利用率都更可预测。显式缓存能让你做一些否则很难做的事情。例如，你可以把会话分叉成两个不同方向并行执行。你也能进行上下文编辑。最佳策略尚不明确，但你确实有更多控制权，而且这种控制权非常宝贵，也让你更容易理解 agent 的成本结构。你可以更好地预测缓存命中率，而其他平台我们发现经常是碰运气。我们在 Anthropic 的 agent 中的缓存策略很直接：一个缓存点放在 system prompt 后；两个缓存点放在对话开头，并随对话尾部不断前移；除此之外还有一些小优化。因为 system prompt 和工具选择必须尽可能静态，我们会在之后的动态消息里提供时间等信息，否则会破坏缓存。我们在循环中也更多利用强化。三、Agent Loop 中的强化每次 agent 调用工具，你不仅可以返回工具的执行结果，还可以向循环中注入更多信息。例如，你可以提醒 agent 宏观目标、子任务状态，也可以在工具失败时提供如何让工具调用成功的提示。另一个用途是在后台状态发生变化时告知系统。如果 agent 会使用并行处理，你可以在每次工具调用后注入状态变化信息。有时 agent 自我强化就够了。例如在 Claude Code 中，todo write 工具本质上是个自我强化工具——它只是接收 agent 给出的一组任务，再原样返回。这基本就是个 echo 工具，但却足以让 agent 推进得比只在上下文开头给任务列表要好得多。我们也使用强化来告诉系统环境是否在执行过程中发生了问题。例如，如果 agent 在某一步失败并重试，但恢复基于损坏的数据，我们会注入消息告诉它应该回退几步重新来。四、隔离失败如果你预计代码执行中会有很多失败，有机会把这些失败从上下文中隐藏。主要方式有两种。第一，把可能需要多次迭代的任务单独运行。你可以在子 agent 中运行任务直到成功，再只把成功结果（可能带一段失败策略摘要）回传。让 agent 看到一些失败尝试是有价值的，因为它可以在后续任务中利用这些信息避免重复错误。第二，并非所有模型都支持，但 Anthropic 支持上下文编辑。我们还没取得太多成功，但觉得非常值得继续探索。上下文编辑理论上可以保留更多 token 用于后续循环。例如你可以从上下文中删除对解决问题没有帮助的失败输出。但如前所述，让 agent 知道“什么没成功”有价值，只是不需要保留全面状态。唯一的问题是：上下文编辑会自动使缓存失效，这是无可避免的。因此是否值得这样做往往难以判断。五、子 Agent / 子推理（Sub Inference）如我之前提过，我们的 agent 多基于代码执行与代码生成。这要求 agent 有一个公共的数据存储位置。我们采用文件系统——在我们这里是虚拟文件系统。为了支持子 agent 或子推理，这要求所有工具都能访问这个文件系统。你应该尽量构建没有死路的 agent。所谓“死路”是指任务只能在某个特定工具内部继续。例如你做了一个图像生成工具，但它只能将图像交给另一个特定工具使用，那就会造成死路。如果你希望把生成的图像打包成 zip，需要代码执行工具能读取这些图像。因此必须让图像生成工具把文件写到虚拟文件系统，而代码执行工具也能读同一位置。反之亦然。你可能需要代码执行工具解压 zip 文件，然后让推理工具描述这些图片，之后再回到代码执行工具继续处理。文件系统就是实现这一点的机制。但这要求所有工具都支持从虚拟文件系统读取路径。因此“ExecuteCode” 工具和 “RunInference” 工具应该都能访问同一文件系统。六、输出工具的使用我们的 agent 不是一个聊天式系统。它最终会输出给用户或外部世界一些内容，但中间所有消息通常不会暴露出去。问题是：它如何生成最终输出？我们有一个专门的输出工具，agent 必须显式调用它来对人类输出。我们通过 prompt 告诉它何时使用该工具。在我们的场景中，输出工具负责发送邮件。但这反而带来很多意外问题。最难的是：相比直接在 agent loop 中输出文本，让输出工具生成“最终信息”时很难控制语气与措辞。我不知道为什么，但推测与模型训练方式有关。我们尝试过让输出工具再调用一个小模型（如 Gemini 2.5 Flash）进行文本润色。但这增加了延迟，而且反而降低输出质量。部分原因是小模型没完整上下文，无法正确措辞。而为了给它更多上下文又会变得昂贵，而且仍不能解决所有问题。有时还会泄露我们不想让最终用户看到的中间步骤。另一个问题是 agent 有时根本不调用输出工具。我们强制要求记录输出工具是否调用过。若循环结束前还没调用，我们会注入强化消息提醒它调用。七、模型选择总体上我们的模型选择最近没有太大变化。Haiku 和 Sonnet 依然是目前最好的工具调用模型，因此非常适合作为 agent loop 的主模型。它们对 RL 的行为也比较透明。另一个明显选择是 Gemini 模型。我们在主循环中并未在 GPT 系列上获得太多成功。对于子工具（例如需要额外推理的工具），我们目前主要用 Gemini 2.5——尤其是处理长文档、PDF、图像信息抽取等任务。特别是因为 Sonnet 系列容易被安全过滤器挡住，处理图像比较麻烦。另外一个显而易见的结论：token 价格并不能决定 agent 的整体成本。工具调用更强的模型能用更少 token 完成任务。有些模型 token 更便宜，但不一定在 loop 中更省钱。总的来说，过去几周变化不大。八、测试与 Evals测试与评估是我们认为最难的问题。这并不意外，但 agent 的特性让问题更棘手。与 prompt 不同，你无法在某个外部系统里轻松做 eval，因为需要提供太多上下文。这意味着 eval 必须基于观测数据或在真实测试运行中进行仪表化。目前我们试过的所有解决方案都没让我们满意。遗憾的是，现在我们还没有找到让人真正开心的 eval 方法。希望能尽快找到，因为这已经变成构建 agent 时最令人沮丧的问题之一。九、Coding Agent 的一些更新关于编码 agent，我的体验没有太多变化。主要的新点是我在试用 Amp。原因不是它一定比我现用的 agent 更强，而是我非常喜欢他们对 agent 的设计方式。从他们公开内容能看出，他们的子 agent（如 Oracle）与主循环交互方式非常优雅，而今天市面上很少有框架能做到这一点。这也是我用它来验证不同 agent 设计方式的原因。Amp 和 Claude Code 一样，让人感觉是“使用者自己做的产品”。行业里并非所有 agent 产品都有这种感觉。十、最近读的东西下面是一些我觉得值得分享的内容。1. 《What if you don't need MCP at all?》：Mario 认为很多 MCP 服务器过度工程化，工具过多占用上下文。他提出一种极简浏览器 agent 方案：只依赖简单 CLI 工具（start、navigate、evaluate JS、screenshot），不仅 token 使用小，而且流程更灵活。我据此做了一个 Claude/Amp 的 skill。2. 《The fate of "small" open source》：作者认为微型开源库时代正在结束，因为平台 API 与 AI 工具足以按需生成简单实用工具。对此我非常认同。3. 《Tmux is love》：没有文章，但结论是 Tmux 很棒。如果你的 agent 要与任何交互式系统工作，都应该考虑添加 Tmux 能力。4. 《LLM APIs are a Synchronization Problem》：这是我最近的一个发现，内容太长写成了另一篇文章。#ai创造营# #程序员# 黄建同学的微博视频

44. 回复@伧僧旧义:跟是不是要用第三方工具没关系，Skill 是用来补充 Agent 本身不具备、而你又“反复”需要的信息：网页链接 //@伧僧旧义:这种无需调用第三方工具的任务需要用 skills吗？用 agent 就可以了吧//@宝玉xp:回复@Tmp_情绪疯子:1. A skill 里面说明完成后调用 B；2. 做个 C Skill，调用A和B//@Tmp_情绪疯子:宝玉老师，我有一个问题想请教一下，例如：目前我有两个skill，一个是需求分析的skill，根据自然语言，分析成产品经理的需求；第二个skill是通过分析后的产品需求，将需求拆解成任务，这个是一个拆解的s

45. 字节开源了一个叫 DeerFlow 2.0 的多 Agent 框架，刚发布就冲上了 GitHub Trending 第一，拿了 43k 星。简单来说，它做的事情是让 AI 像一个团队一样协作干活。你给它一句话，比如「帮我研究 AI 行业趋势，然后做一份 PPT」，它会自动把任务拆开，分配给不同的 Agent，并行执行，最后把成果汇总交付给你。整个过程不需要你一步步盯着，直接出结果。它能做到这些，靠的是底层几个关键设计：多 Agent 之间的协同机制，带记忆的上下文管理，沙箱环境里的安全执行，以及可扩展的技能体系。报告、PPT、网站、视频这些不同类型的产出，都可以通过挂载不同的技能模块来实现。核心能力总结起来就三点。第一，多 Agent 协作，一个 AI 相当于一个团队，不同角色各司其职。第二，技能可扩展，你可以根据需求给它加新能力，覆盖面很广。第三，完整的工作流执行，从接收任务到最终交付，中间不需要人工介入。这个框架的意义在于，它把 AI 从一个你需要反复对话、手动引导的助手，变成了一个你扔过去一个目标、它自己就能跑完全程的执行团队。开源项目地址：github.com/bytedance/deer-flow#科技先锋官##How I AI#

46. 【本周GitHub最疯狂的24小时：AI Agent项目集体爆发】快速阅读：这周GitHub增长最快的项目几乎全是AI Agent基础设施，从完整的AI代理系统到用Zig写的专用浏览器，星标增长速度惊人。这不是应用层的爆发，而是工具层的军备竞赛——真正的战场还没开始。---增长榜单：1. agency-agents 一周涨23.2K星，提供前端开发、社区运营、事实核查的完整AI代理系统2. superpowers 涨19.2K星，插件式技能框架，刚突破10万星3. MiroFish 涨17.6K星，群体智能预测引擎4. OpenViking 涨10.2K星，火山引擎开源的Agent上下文数据库5. lightpanda-io/browser 涨9.9K星，专为AI设计的无头浏览器，用Zig编写还有阿里的page-agent（用自然语言控制网页界面）、吴恩达的context-hub（上下文管理层）、微软的BitNet（1-bit大模型框架）等。有意思的是评论区的分裂。有人说“用Zig写的无头浏览器值得关注，瓶颈正在从模型能力转向执行基础设施”。有人直接断言“大多数网站的未来是零UI”。也有人泼冷水：“95%的Agent框架只是包装器，一遇到生产环境就崩溃。真正有价值的是能处理错误恢复的那个。”另一个观察：“阿里、微软、吴恩达同一周发布Agent基础设施，说明基础层还在构建中。Agent领域的赢家还没确定，大家都在抢占底层。”最扎心的评论：“我们在给它们配备无头浏览器之前，它们连可靠的测试套件都写不好。”星标增长快不等于实际采用。一周涨23K可能只是沮丧的开发者在寻找替代方案。六个月后回看，还在被使用的才算数。ref: x.com/sharbel/status/2034968576696688689#AI创造营##人工智能#

47. 都有这么多 Agent SDK/框架了（我应该没列全吧）一、OpenAI Agents SDKOpenAI 推出的 Agents SDK 是目前最轻量、最直接的 Agent 开发方式。它原生支持 Python 和 TypeScript，语法简洁，几行代码就能让 LLM 调用外部函数、工具或执行任务。1. 与 OpenAI 模型的无缝集成，尤其是函数调用、上下文管理等特性。2. 支持 multi-agent handoff 与任务链式调用，便于扩展复杂逻辑。3. 具备生产友好的可观测性与追踪机制。它非常适合快速原型和中小规模生产项目，是“入门写 agent” 的理想起点。二、LangChainLangChain 几乎是 LLM 应用开发的“标准库”。其 Agents 模块为 LLM 封装了链式推理、工具调用、上下文记忆等能力。1. 概念丰富——有 Chain、Tool、Memory、Agent、Retriever 等模块，适合构建复杂系统。2. 插件与生态极其庞大，几乎支持所有主流模型与数据源。3. 提供跨语言支持（Python 与 JavaScript/TypeScript）。LangChain 上手门槛略高，但生态完整，非常适合需要可扩展架构的项目。三、LangGraph用“流程图”思维管理 Agent 状态。LangGraph 是 LangChain 的“升级版本”，它将 Agent 系统抽象为状态机＋有向图，可以显式地控制 Agent 间的消息流与执行路径。1. 天然适合多 agent 协作、任务编排和状态回溯。2. 支持持久化与可视化，能直观看到系统执行流程。3. 面向生产级场景，具备清晰的错误恢复与检查点机制。如果你想做一个“多 Agent 系统”，LangGraph 几乎是最强大的开源选择。四、Google ADKGoogle 的 ADK（Agent Development Kit）主打可扩展性与安全性。它不是轻量原型工具，而是企业级 Agent 平台。1. 多语言支持，深度集成 Google 生态（Vertex AI、Gemini 等）。2. 工具调用能力极强，可直接对接云服务、API 与企业系统。3. 自带日志、监控、可观测性与治理能力。适合需要在企业内部署、具备高可靠性要求的 Agent 系统。五、SmolAgentsSmolAgents 是Hugging Face推出的一款轻量 Python 库，设计理念是“最小可行 Agent”。1. 安装简单、API 极少，几分钟即可跑通一个工具调用示例。2. 灵活支持 tool 注册与函数调用，但不追求完整框架。3. 适合快速原型、实验性项目或教育用途。如果你希望“几行代码让 LLM 动起来”，SmolAgents 是最轻便的起点。六、AutoGenAutoGen 最初由 Microsoft 研究团队推出，用于多 Agent 间的对话协作。它以“角色对话” 为核心，支持 LLM 代理之间互相交流、分工、调度任务。1. 多 agent 结构灵活，可模拟协作团队。2. 支持复杂任务分配与循环反馈。3. 对研究者和实验系统尤其友好。如果你的目标是研究 agent 交互机制或自动化工作流，AutoGen 是很好的基础。七、MetaGPT角色驱动的 Agent 系统。 MetaGPT 是一个以“AI 团队”为核心的框架，设计理念是让多个 agent 分别扮演项目经理、工程师、设计师等角色，共同产出结果。1. 多角色、结构化协作，任务拆解逻辑强。2. 擅长长链路流程（如产品需求分析→代码生成→测试）。3. 适合自动化软件工程类场景。如果你希望让 LLM 们“像一个团队一样协作”，MetaGPT 是不错的模板。八、Haystack AgentsRAG 与 Agent 的结合体。Haystack 原本是一套开源 RAG 框架，如今扩展出了 Agents 模块。它擅长将检索、知识库与 LLM 推理结合。1. 内置文档检索、索引、管道机制。2. 适合企业知识问答、文档助手类 agent。3. 与 LLM 、数据库和 vector store 的集成成熟。如果你的 agent 核心任务是“带知识的问答”，Haystack 是现成方案。九、Claude Agent SDKAnthropic 推出的开发包。它基于其先前产品 Claude Code 的 agent 引擎（agent harness）构建，目的在于为开发者提供“从模型调用 + 工具调用 +流程控制 +状态管理”这一整套能力。1. 上下文管理自动化：自带对话／会话上下文的压缩与管理机制，避免因上下文过长导致模型性能下降。 2. 丰富的工具生态：包含文件操作、代码执行、网络搜索等内置工具，并支持扩展自定义工具／插件。 3. 权限与安全机制：可以细粒度控制 agent 可使用的工具、权限模式（例如 allowedTools、disallowedTools）等。 4. 生产化准备特性：例如会话管理、错误处理、监控能力、模型优化／提示缓存机制。 5. 插件和扩展支持：通过插件机制（如自定义命令、子 agent、技能集、MCP 服务器）可创建复杂系统。#ai创造营# #程序员#

48. 绿联科技 × MiniMax 达成战略合作！🎉NAS行业首家，原生内嵌MiniMax大模型，OpenClaw开箱即用！绿联NAS应用中心一键安装，一会就安装试试看。👉还有30天全量免费使用。@UGREEN绿联# 绿联NAS私有云## OpenClaw#

49. Clawdbot 之后，我们离能规模化落地的 Agent 还差什么？

50. ClawTeam：让 AI Agent 自主组建团队、分配任务、协同工作的 CLI 工具github.com/HKUDS/ClawTeam/港大开源的一个项目：“AI 编程 Agent 很强大 —— 但它们各自为战。当任务太大时，你只能手动拆分工作、复制粘贴上下文、合并结果。如果 Agent 能自己组队呢？ClawTeam 实现了 Agent 群体智能（Swarm Intelligence）—— Agent 自主组建团队、分工协作、共享发现、收敛到最优方案。一个 Leader Agent 可以： 🚀 创建子 Agent —— 每个子 Agent 拥有独立的 Git Worktree 和 tmux 会话 📋 分配任务 —— 支持依赖链，完成时自动解除下游阻塞 💬 发送消息 —— 向任意子 Agent 发送指令 📊 监控进度 —— 查看看板、读取实验结果 🔄 调整方向 —— 终止低效 Agent，用新方向重新分配人类只需提供初始目标，群体智能完成剩下的一切。”#How I AI#

51. Bash Is All Agent Need：Anthropic 重新定义智能体开发

52. 给建议的AI看够了？MiniMax Agent 让AI直接住进你的电脑干活#AI新星计划#科技改变生活#MiniMAX#Agent#minimaxagent

53. 2025年，Agent对于打工人真的有用吗？实测OK Computer

54. 刚从 #中关村北纬龙虾大赛# 决赛现场回来，全程看完30个项目，最大感受不是震撼，是后怕。#北京范儿# 学术、生产力、生活三大赛道，每个都在用智能体重塑“功能”的边界。#OpenClaw# 开源仅2个月，颠覆来得太突然了。海淀用一场比赛告诉我们，APP的倒计时已经开始了。我们离“手机里不再需要APP”的那一天，可能比想象中近太多。视频不长，但值得你认真看完。APP时代正在加速落幕，智能体才是未来方向。#微博超有用视频大赛##微博vlog大赛##有点东西##微信龙虾插件# http://t.cn/AXfHUc10

55. 半夜，小米大模型团队发布小米全模态Agent基座大模型 MiMo-V2-Omni“MiMo-V2-Omni 专为现实世界中复杂的多模态交互与执行场景而生。从底层构建了融合文本、视觉、语音的全模态基座，并以统一架构将“感知”与“行动”深度绑定。这不仅打破了传统模型“重理解、轻执行”的局限，更让模型原生具备了多模态感知、工具调用、函数执行及 GUI 操作能力。”“MiMo-V2-Omni 可无缝接入各种 Agent 框架，实现了从理解到操控的跨越，大幅降低了全模态 Agent 的落地门槛。”“在正式发布之前，我们将一个早期测试版本以「Healer Alpha」为代号匿名上架 OpenRouter，没有任何宣传，纯粹让模型能力说话。结果调用量自然攀升至平台前列，并在 OpenClaw 测评榜单 PinchBench 上拿下均分第一，用户和基准双双给出了同一个答案。” “我们还与金山办公合作，将 MiMo-V2-Omni 接入 WPS Office，探索全模态智能体模型在日常生产力场景中的表现。”

56. 一键接入OpenClaw，谷歌开源CLI狂揽15k Stars，Agent开始接管Workspace

57. 以「更懂开发者」之名：2026全球开发者先锋大会，看Agent如何重塑生产力

58. LLM 的记忆问题「很快」就不再是问题了？

59. PRDBench：面向 PRD 的项目级 Code Agent 评测新基准

60. RAG、LangChain、Agent 到底有什么关系？

61. 在线做AI研究助手，信息查找、论文审阅、实验复现多任务轻松搞定？Feynman 是一个开源 AI 研究代理项目，集合了多智能体协作、文献检索、批判性评审、实验复现等功能，帮你高效产出生信可靠的科研成果。它支持自然语言交互，指令也能自动调动不同agent工作，比如：- /deepresearch <话题> ，聚合大量论文和资料深入探讨- /lit <话题> ，完成权威文献综述- /audit <论文编号>，对比源代码核验论文结论- /replicate <实验>，本地或云端复现实验流程还内置了基于Pi框架的agent运行时和alphaXiv文献解析大脑，输出的所有内容都附带精准引用。多平台运行依赖Node.js环境，支持Web、CLI等形式，适合AI科学家、工程师和研发团队加速创新。GitHub：github.com/getcompanion-ai/feynman主要特点：- 多智能体自动协作，提升研究深度与广度- 完整文献检索、批评复审和实验复现链条- 结构化输出，方便撰写论文和报告- 支持Docker容器，保证安全隔离执行- 自动链接文献和代码，确保结果透明可信让科研不再是孤军奋战，Feynman做你靠谱的研究伙伴！#AI创造营# #人工智能# #开源# #科研利器#

62. “龙虾”之后，网易同传Agent重新定义翻译工具

63. Agent的底层原理就这么简单：别被玄学忽悠，手撕核心代码给你看

64. 27岁清华学霸姚顺雨掌舵腾讯AI 27岁清华学霸姚顺雨掌舵腾讯AI，一个98年出生的年轻人，从清华姚班到 OpenAl，再到腾讯首席AI科学家，顶级人才回流，AI竞赛正式进入agent时代！#AI #腾讯 #agent

65. 真正的核心竞争力，来自于驾驭工具。 #大咖观察 #红衣聊AI #编程 #人工智能技术

66. 别等别人赚钱才后悔，你的AI该“嵌入”业务了。 #大咖观察 #红衣聊AI #AI工具

67. GDC观察：游戏大厂都来聊AI，“游戏AI”的新规则由谁制定？【硅谷101】

68. 探访云栖（二）：AI Agent元年，谁在打造“数字员工”？【101 Weekly】

69. Qwen3.5 开源王炸！多模态性能屠榜，本地部署 + OpenClaw 实战全流程！|零度解说

70. 老外还在幻想的事，已经被腾讯做出来了？全网都在养龙虾，腾讯游戏直接把龙虾Agent塞进了研发流水线。 GDC 2026，腾讯游戏一口气甩出 21 场 AI 分享，不聊空话，直接把参数规模、训练时间、工程链路和落地细节全部摊牌。尤其是天美的 Ignis Agent，让我第一次真正感受到：AI 进入游戏行业，已经不是做 Demo，而是开始接管复杂研发流程。相比其他AI应用场景，游戏的确是一个高度复杂的实时系统。因此，像腾讯这样能把AI嵌入复杂游戏工程、在玩家交互中持续打磨并完成长期迭代的游戏厂商，才更有可能引领游戏AI化的下一阶段探索，成为AI时代游戏产业新的规则制定者。 #AI #人工智能 #Agent #智能体 #GDC

71. MiniMax Agent 开年更新，好的 AI 产品，需要让工具来适应人了

72. Claude 工具调用迎来重大升级简单来说，Claude 的工具调用方式从一问一答变成了写代码批量处理。以前的流程：用户提问 → Claude 调用工具 → 拿到结果 → Claude 再决定下一步 → 再调用工具 → 循环往复现在的流程：用户提问 → Claude 先写一段代码 → 这段代码自动调用工具、解析结果、根据条件判断下一步操作 → 最终把处理好的结果交给 Claude核心变化是：Claude 不再每次调用工具后都要"回来想一想"，而是提前用代码把各种可能的情况都规划好，一次性执行完。实际效果有多好？以网页搜索为例，Sonnet 4.6 在 BrowseComp 基准测试上准确率提升了 13%，同时输入 token 减少了 32%，又快又准。以前 AI Agent 每一步都要请示大模型做决定，现在 Claude 可以预先把成百上千种决策路径写进代码里，一次性跑完。这相当于把原来需要多轮 LLM 调用的循环压缩成了一次代码执行，效率提升的潜力非常大。除了搜索之外，代码执行、网页抓取、记忆、程序化工具调用等功能也同步正式上线了。

73. Manus 把 Agent 的工具分成了 3 层：第 1 层：函数调用 (Function Calling)这是最基础的一层，只保留一小组固定的、原子化的函数，比如：读写文件、执行 Shell 命令、搜索文件等。在 LLM 的系统提示词中就只有这一层的工具定义，相对比较少，15 个以内，输入格式和输出格式都很清晰，不容易出错，但这里面有两个工具很特殊，一个是 Shell，一个是 File。第 2 层：沙箱工具 (Sandbox Utilities)每个 Manus 会话都运行在一个完整的虚拟机沙箱里。就是原推文提到的，虚机预装了很多命令行工具，比如格式转换器、语音识别工具，甚至一个 mcp 命令行客户端。然后这些工具都通过第 1 层中定义的 Shell 来调用，就是命令行工具，命令行调用。但是这么多工具模型怎么知道呢？Manus 在系统提示词里会直接告诉 LLM，在一个特定的文件夹里有很多预装的命令行工具。对于最常用的工具，直接列出它们的名字。不常用的，LLM 可以直接通过原推提到的命令列出所有命令行工具，通过 --help 参数来查看任何一个工具的用法，因为所有这些工具都是他们自己开发的，格式统一。第 3 层：代码包与 API (Packages and APIs)这一层其实就是 LLM 实时编写 Python 代码，通过代码实现更复杂的功能。比如用户想查询某个 API 的数据，可以直接用 Python 写一个函数，fetch API 的数据，并解析成需要的格式。其实在 Codex 中，用 Python 代码当工具已经用的很多了。由于复杂的运算都是代码完成的，返回给主 Agent 的知识计算后的结果，所以并不会占用主 Agent 的上下文。这样 3 层设计的好处是，从模型的角度看，它需要调用的工具就固定是第 1 层的十几个，而借助命令行和代码，它又可以衍生出无数的工具组合。还有一点就是我在之前推文提到的子智能体，Manus 也是大量采用“智能体即工具 (agent as tool)”的模式。把子智能体当工具用，比如负责检索是一个子智能体，但是这个子智能体在主 Agent 看来就是一个工具。同时也可以很好的起到减少上下文的效果。

74. 关于 AI Agent，你最想知道的 3 个问题——为什么我说“垂直 Agent”是个伪命题回答几个读者问题。1、AI Agent 是否有一个权威的概念？中美两国对这个概念是否有统一的解释？AI Agent 的定义和国家无关，更多是行业共识的演进。目前业界比较认可的定义来自 Anthropic。他们在《Building Effective Agents》（网页链接）这篇文章中做了一个很重要的区分：工作流（Workflow）：通过预定义的代码路径来编排 LLM 与工具的系统。Agent：由 LLM 动态地指挥自己的流程和工具使用方式的系统，始终由 LLM 来掌控完成任务的方式。简单来说，工作流是“人写好剧本，AI 照着演”；而 Agent 是“人给个目标，AI 自己想办法”。从技术实现角度，我比较认同 Simon Willison 提出的简洁定义（网页链接）：一个 AI Agent（智能体），是为了实现某个目标，循环调用工具的大语言模型。这个定义抓住了 Agent 的本质——它不是一次性给出答案，而是通过“思考→行动→观察→再思考”的循环，逐步完成任务。目前主流的 Agent 实现，无论是 OpenAI 的还是 Anthropic 的，底层都是这个结构。当然，不同公司可能会根据产品定位给出略有差异的表述，但核心思想是一致的：Agent = LLM + 工具调用 + 自主决策循环。2、近期国内外大厂密集推出 AI Agent，为何选择这个时间点？您如何看待 AI Agent 的商业化前景？大厂在这个时间点密集推出 Agent，核心原因是：Agent 是目前 AI 落地最有价值的方向。为什么 Agent 比聊天机器人更有商业价值？聊天机器人的局限性很明显——它只能“说”，不能“做”。而 Agent 能够：• 调用工具：比如搜索网页、读写文件、执行代码• 完成复杂任务：把大任务拆解成小步骤，逐个完成• 与外部系统集成：对接企业内部系统、数据库、API• 持续运行：不需要人一直盯着，可以在后台自主工作这意味着 Agent 可以真正替代人完成一部分工作，而不只是辅助回答问题。已经跑通的场景：编程领域编程是 Agent 最先落地的领域。像 Claude Code、Cursor、Codex 这样的编程 Agent，已经能够实实在在地帮开发者完成任务，不只是生成代码片段，而是理解需求、读取项目代码、修改文件、运行测试、修复 bug，整个流程都能自主完成。正在爆发的方向：Skills 生态去年底开始，“Skills”这个概念开始流行。简单理解，Skills 就是教会 Agent 完成特定任务的“技能包”，一套预设的工具、提示词和工作流的组合。比如我个人就大量使用 Claude Code 结合各种 Skills 来提升效率：• 给文章自动配图（调用图片生成工具）• 根据素材生成漫画故事• 根据素材自动生成 PPT• 自动发布文章到公众号、博客、社交媒体• 等等这些任务以前每个都要花我半小时到几小时，现在几分钟就能完成。顺便说一下，我这几个 skills 都是开源的：github.com/JimLiu/baoyu-skills/issues现阶段的挑战但 Agent 目前仍处于早期阶段，主要挑战有：1. 门槛较高：目前这些能力主要在极客圈子里流行，普通用户上手困难2. 安全问题：Agent 需要较高的系统权限才能工作，这带来了安全风险。比如恶意的 Skill 可能窃取数据、攻击系统3. 可靠性：Agent 有时会“跑偏”，需要人工干预这些问题都在被逐步解决。大厂密集入场，本质上是看到了 Agent 的巨大潜力，想要抢占生态位。谁能率先建立起最多用户的 Agent 客户端和丰富的 Skills 生态，谁就能在下一阶段占据优势。就像现在 Anthropic 就依赖 Claude Code 抢占了先机和用户心智，大家想到 Coding Agent 先想到 Claude Code，MCP、Skills 的标准也是他们提出来的，开发者们争先恐后的基于他们的标准在构建 Agent 生态。3、通用类 AI Agent 和垂直类 AI Agent，您更看好哪个的商业前景？这个问题需要换个角度来理解。Agent 本身难以形成垂直壁垒从技术角度看，Agent 本身没有任何秘密，就像我前面说的，它从技术角度看就是一个循环调用工具的大语言模型。而模型对所有人来说都是一样的：要么花钱用商业模型（OpenAI、Anthropic、豆包、阿里），要么用 DeepSeek 这样的开源模型。这就像选操作系统，你用 Windows 还是 Linux，大家都能用。所以，单纯做一个垂直领域的 Agent 很难建立护城河。你今天能做，别人明天也能做，而且可能做得更好。真正的机会在哪里？打个比方：Agent 就像操作系统，无论是通用领域还是垂直领域，操作系统本身都差不多。真正的差异化，是基于操作系统之上的应用。垂直领域真正的机会在于：1. 独有的数据：你有别人没有的行业数据、客户数据、知识库2. 专业的 Skills：针对特定行业流程打造的工具和工作流3. 深度的集成：与行业内已有系统的对接能力4. 领域 Know-how：对行业痛点和流程的深刻理解举个例子：一个医疗领域的 Agent 产品，核心竞争力不是“Agent”这层，而是背后接入的医学知识库、与医院 HIS 系统的对接、对诊疗流程的理解、以及多年积累的脱敏病例数据。所以我的结论是：不要去做“垂直 Agent”，而是用通用 Agent 的能力，去解决垂直领域的问题。护城河不在 Agent 这层，在你围绕 Agent 构建的数据、工具和行业理解。以上是我基于一线实践的观察和思考，仅供参考。

75. 今天我们开源了一个新的AI Agent项目。Wegent：一个能够定义、编排和执行Agent团队的开源系统。和其它Agent开发系统的区别是，Wegent底层使用声明式方式构建和编排 AI Agent，这就意味着部署智能体就像是在K8S里部署负载一样，可以实现基于yaml直接定义部署Agent服务。同时，Wegent的底层定义中区分了智能体的“Ghost（提示词）”和“Shell（执行器）”的概念。例如，你既可以把Claude Code作为智能体的“壳”实现远程编码Agent系统，也可以基于Agno的“壳”来实现DeepResearch系统。在开源项目里也增加了配套的前端服务，可以直接在网页中构建新的Agent团队。项目地址：github.com/wecode-ai/Wegent（附件是用Wegent实现的网页版Claude Code的效果）

76. Wegent是一个开源的多Agent智能体构建和运行平台，本周项目做了一些更新：1 拆分Chat模式和Code模式，优化各自模式的UI/UX2 使用Claude Code执行引擎时，可以展示详细的执行步骤3 优化了单任务的追问效果github.com/wecode-ai/wegent 欢迎关注

77. 【#字节版OpenClaw上线#】#字节版龙虾上线# 近日，“养龙虾”热潮袭来。3月9日中午，火山引擎在官方公众号发文称，正式上线ArkClaw——开箱即用的云上SaaS版OpenClaw。无需复杂配置，打开网页即可使用7x24小时在线的AI助手，轻松养“虾”。火山引擎表示，OpenClaw带来了强大的Agent能力，但无论是云端还是本地部署都需要复杂的环境配置，并且手动配置API Key等流程，对非技术用户门槛较高。在实际使用时，开发者也常常会面临重启后对话记忆清空、进程中断、会话故障等问题。基于以上痛点，火山引擎推出Web端直接开箱即用的ArkClaw，除了在网页端进行交互，ArkClaw已支持多种主流即时通讯App，并深度适配飞书OpenClaw官方插件。用户使用飞书处理任务更丝滑，无需反复配置权限或者复制上下文给ArkClaw，即可处理飞书日程安排和提醒、复杂文档/表格处理等任务。目前，ArkClaw“龙虾”可以使用Doubao-Seed-2.0系列、Kimi2.5、MiniMax2.5和GLM等主流模型。目前，火山引擎CodingPlan用户可以抢先使用ArkClaw。

78. #蚂蚁集团开源 Ring-2.5-1T#国产万亿参数模型跻身“第一梯队” 🐜🌌就在今日，蚂蚁集团正式宣布开源其自研的万亿级思考模型 Ring-2.5-1T。这不仅是国产大模型在参数规模上的又一次飞跃，更在深度推理（Reasoning）、极致代码（Coding）以及复杂Agent协作能力上，直接对标并适配了全球顶尖的开发者工具链。【评论】蚂蚁这次开源 Ring-2.5-1T，核心看点不在于“大”，而在于“强逻辑”与“生态亲和力”。在 DeepSeek 引发全球开源模型竞赛后，蚂蚁选择在 1T（万亿）这个级别发力，显然是为了解决大模型在处理长链条、高逻辑复杂度的 Agent 任务时的“幻觉”痛点。通过完美适配 Claude Code 和 OpenClaw（此前由蚂蚁主导的 Agent 框架），蚂蚁实际上在构建一套**“国产底座 + 全球生态”**的开发者范式。当模型学会像人类一样“思考”再输出，AI 的应用边界正式从“聊天机器人”跃迁为“全自动工程专家”。

79. Manus被Meta收购，这是中国AI路线的一次胜利。 #大咖观察 #红衣聊AI #manus #Meta #agent

80. 2025过去了！这一年你是不是也在为AI焦虑？老周用360一整年的实践，告诉你答案：不用怕，抓住Agent就赢了！从我自己敲代码做100多个智能体，到带领团队All in，这条AI布道之路，全是实战干货。 2026，你想和智能体一起搞定啥？评论区留言，老周帮你研究！#大咖观察#2026 #年度总结 #红衣聊AI #agent

81. AI编程大战正式开打！ Claude vs GPT同一天放大招，不是比谁代码写得好，而是AI开始自己组队当项目经理了。#大咖观察 #红衣聊AI #编程 #ChatGPT

82. 不用折腾部署 OpenClaw，我用 MiniMax Agent 一键养「龙虾」，还拍了个短剧

83. 补齐OpenClaw进化拼图！AReaL v1.0开源，智能体强化学习「一键接入」

84. 2026企业级智能体白皮书｜甲子光年智库

85. #千问Qwen3.5大模型发布#千问 Qwen3.5 是采用极致稀疏 MoE 架构在保持超强性能的同时，显存占用降低 60%，推理效率大幅提升，部署成本显著下降。模型支持最高 256K 超长上下文，让长文本处理变的更加的轻松有效率了！原生多模态统一也是Qwen3.5的特点之一，也是目前国内外大模型的发展的主要趋势，模型在图文、视频理解能力全面升级，精准解析图表、文档与复杂视觉内容。实现了一个入口实现多种属性。Qwen3.5对于中小企业特别友好，很大程度上降低了企业运营成本，可以让中小企业得到高效、普惠、全能的运营工具。不再因为高昂的费用而排斥企业去追逐AI。#过个有AI年##HOW I AI#

86. 为什么在生产环境部署多智能体系统（Multi-Agent）容易出现成本失控，有哪些常见的踩坑场景？

87. 小扎秘密研发CEO Agent！开源「人生托管系统」爆火

88. 值得关注：制造业AI落地的成功案例来了#制造业 #JetPave #AI #捷配科技

89. 你以为你看到的是AI的想法，实际上你看到的是：人类行为模式的一次完整数字回放。#大咖观察 #红衣聊AI #人工智能技术 #agent #AGI

90. 「Github一周热点107期」OpenAI收购的AI安全工具、AI代理事务所、OpenClaw技能库、claude code插件和上下文数据库

91. 目前最强OpenClaw安装分享！对接飞书！普通人最该体验的AI Agent项目

92. 快抄作业！我用JoyAgent搞了个AI团队 2025年都快结束了，Agent是不是还没用上？我找到了打工人用上智能体的最简单方法，就是用JoyAgent把每天重复的SOP全做成Agent，不懂代码也能零门槛搭建，而且效果很稳定。看着AI团队全自动打工、出活，非常解压。 #AI #智能体 #JoyAgent #JoyCode #京东云

93. AI Agent落地“卡壳”？腾讯云用100毫秒沙箱打通“最后一公里”｜甲子光年

94. Moltbook 保姆级部署教程：从 0 到 1 本地运行 AI Agent（OpenClaw 对接） | 零度解说

95. 阿里云、百度云突然涨价，算力最高暴涨 34%，存储直涨 30%，AI 全面进入付费时代！很多人把涨价当成行业倒退，认为成本飙升会直接掐灭中小厂的 AI 转型希望。但我偏要讲句实话：这不是 AI 普及的终点，而是行业挤泡沫、去虚火的关键一步。一边是成本压力陡增，中小企业叫苦不迭；一边是行业乱象丛生，低质应用泛滥。落地环境本就不健全，如今再遇成本上涨，AI 行业真的无路可走了吗？中小企业的抵触情绪该如何化解？高成本与难落地的双重困局又该如何破局？本期视频直接给出尖锐观点与现实解法，颠覆你的认知！#AI生活指南##微博超有用视频大赛##科普大作战##科技先锋官# 种斌Marco的微博视频

96. 中小企业做AI，真的只能被算力、成本、技术卡死吗？别慌！华为最新发布的AI数据基础设施，号称要打破中小企业AI转型的死局！有人说它是中小企业的救命稻草，OceanStor A800兼容旧设备、护投资，FusionCube A1000开箱即用、提效80%，彻底降低入门门槛；也有人质疑，这不过是巨头的又一次布局，中小企业真能靠它逆袭？它到底是帮中小企业突破瓶颈、激发创新，还是换种方式绑定企业？为什么说它能让中小企业不用再烧钱做AI？这条视频，拆解华为AI基础设施的真相，揭秘它能否真正赋能中小企业。#AI生活指南##微博超有用视频大赛##科普大作战##科技先锋官# http://t.cn/AXf4SD2c

97. 回复@浮图客栈:pi 不错，openclaw 是基于它搭建的，我也是用的它自己搭的：github.com/badlogic/pi-mono //@浮图客栈:请教宝玉老师，现在主流agent框架除了openclaw还有哪些？或者宝玉老师一般是自行搭建自己的agent框架吗？//@宝玉xp:软件为 Agent 提供了 CLI 或者 MCP，网页现在为了 Agent 直接返回 Markdown 而不是 HTML。在加速了。 http://t.cn/AXtUIyyI http://t.cn/AXtUIyyM

98. Agent-Kernel ，浙大搞得一款用户友好的多智能体系统开发框架，深度赋能大规模社会模拟，为探索大规模群体智能提供无限可能。github.com/ZJU-LLMs/Agent-Kernel/Agent-Kernel 支持：运行时动态增减大模型智能体；智能体数量无限扩展；模拟过程中实时干预；智能体行为和大模型输出的验证与审查；跨模拟场景代码复用。Agent-Kernel 已成功应用于多个复杂的社会模拟场景：图1 25 号宇宙，模拟著名的“25 号宇宙”社会学实验，以探索人口密度、社会结构与行为异常之间的关系。图2 浙江大学校园生活，构建高保真度的校园环境模拟，用于研究行人流动动态、资源分配和社会互动模式。#AI创造营##科技先锋官#

99. #钉钉宣布接入OpenClaw# API调用限时全免费，面向中小企业推普惠课程 🤖3月10日，钉钉宣布从即日起至2026年3月31日，企业和个人开发者在使用OpenClaw时，调用钉钉相关API、Webhook或Stream服务，可获得不限量的免费调用额度。接入后，用户可通过OpenClaw直接调用钉钉AI表格、Teambition等产品技能，实现创建表格、数据整理及自动化任务处理、项目管理等操作。同时，钉钉将面向中小企业推出实战课程，帮助管理者和开发者从认知到实操掌握OpenClaw与钉钉的集成应用，将AI真正落地在业务场景中。【评论】“技术普惠”组合拳，钉钉正在降低中小企业拥抱AI的门槛当API调用“不限量免费”，当实战课程手把手教落地，钉钉这波操作瞄准的是中小企业最真实的痛点：有AI焦虑，但缺技术门槛。OpenClaw作为开源AI Agent框架，与钉钉打通后，让“聊天式调用AI、跨平台执行任务”成为可能。这不是简单的功能开放，而是用“免费+课程”的双重杠杆，把AI从大厂的“奢侈品”变成中小企业的“日用品”。在AI应用落地的关键窗口期，钉钉赌的是：谁能帮企业跨过第一道坎，谁就能成为未来十年的默认选项。

100. AI革命不是让你去学写代码，而是让你学会指挥AI干活。 #大咖观察 #红衣聊AI #科技改变生活 #人工智能

101. Agent Infra到底是什么？【AI基建】

102. AI也可以组建团队了港大开源的新项目ClawTeam感觉像是让AI Agent从单机到了集群，不同于当前主流的单Agent工具，ClawTeam引入了领导型Agent。当我们下单目标，它就会自主将复杂任务解构为子任务。从开发到部署的全流程自动化，ClawTeam的全栈闭环将原本需要人工干预的DevOps流程转化成了Agent群体的内部协作。如果说OpenClaw解决了“手”的问题，ClawTeam就是在试图解决“脑与神经网络”的问题吧 #ai##ai前沿速递##微博兴趣创作计划#

103. 一键部署Openclaw还能白嫖算力？绿联NAS送你“小龙虾”！

104. #国产AI龙虾谁更好用#对于普通用户来说，选国产AI龙虾不用太纠结参数，优先看重好不好上手、稳不稳定。有些产品配置复杂、门槛偏高，只适合技术爱好者；有些开箱即用、操作简单，更适合日常使用。用着顺手、不翻车，比什么都重要，慢慢培养不断磨合才更容易get到好用的龙虾。

105. 刚开始接触 Claude Code 的朋友，强烈推荐你去看一个项目，叫 learn-claude-code。这个课程教的不是怎么用 Claude Code，而是带你从零实现一个类似 Claude Code 的 AI 编码 Agent。整个项目分成 12 节课，每节只加一个机制，代码从几十行慢慢长到完整版，每节都有独立可运行的 Python 文件，学起来非常丝滑。简单列一下课程脉络：前三节打基础。先搭一个最简单的 Agent Loop 加一个 Bash Tool，能跑起来就行。然后加上 Tool 的注册和调度机制，再让 Agent 学会先做计划再动手。中间几节加能力。子 Agent 拆分大任务，Skills 动态加载，上下文压缩，任务持久化加依赖图，后台异步执行。每一节都是在前一节的基础上叠加一层，逻辑很清晰。最后三节搞协作。多 Agent 组队，定义团队沟通协议，让 Agent 自主认领任务，最后用工作树做完全隔离，互不干扰。课程结尾还有一个 s_full.py，把 12 节课的所有功能合在一起，就是一个完整的 AI 编码 Agent。学完这个项目，你对 Claude Code 底层在干什么就彻底通透了。知其然也知其所以然，用起来完全是另一个境界。仓库地址：github.com/shareAI-lab/learn-claude-code在线学习平台：learn.shareai.run（建议先打开这个看可视化，体验非常好）中文 README：github.com/shareAI-lab/learn-claude-code/blob/main/README-zh.md#How I AI##科技先锋官#

106. nanobot 是香港大学数据科学实验室（HKUDS）开源的一个超轻量级个人 AI 助手，灵感来自 Clawdbot（OpenClaw 项目），但代码量只有约 4000 行，比 Clawdbot 的 43 万行精简了 99%。核心卖点：极简但功能完整——支持多 LLM 提供商（OpenRouter、Anthropic、OpenAI、DeepSeek、Gemini、Groq 等）、本地模型（vLLM）、多渠道接入（Telegram、WhatsApp、飞书）、网页搜索、定时任务、持久记忆和 Skills 扩展，全部用很少的代码实现。典型使用场景包括：实时市场分析、全栈开发辅助、日程管理、个人知识库问答。部署方式很简单： pip install nanobot-ai 安装后，配置一个 JSON 文件填入 API Key，就能通过命令行聊天或挂载到 Telegram 等渠道 24/7 运行。也支持 Docker 部署。这是一个面向研究和学习的项目，代码干净可读，适合想理解 AI Agent 架构的开发者拿来学习和二次开发。项目刚发布几天（2026 年 2 月 2 日上线），还在快速迭代中。github.com/HKUDS/nanobot 网页链接

107. #AI龙虾到底能干什么# 能干的不少，像是可以变成办公助手，整理邮件安排定时推送；或者对接包括PDF、Word等文件快速转换格式，给论文、一些资料进行总结，建立自己的知识库等。作为一个开源的AI Agent框架，能做到这样其实已经很出彩了

108. 最近发现一个被严重低估的开源项目，叫 Apify Agent Skills，它能彻底改变 AI Agent 获取数据的方式。简单说，装上这个 skill 之后，你的 Claude Code 或者 OpenClaw 就能直接变成一个互联网情报搜索引擎。它和现有的抓取工具比起来，有几个明显的优势。首先是专业性。它背后有将近 2 万个专门针对特定平台打造的爬虫 Actor，每个都是为某个具体场景优化过的，不是那种什么都能干但什么都干不好的通用工具。其次是自动化。你只需要提需求，它会自动帮你找到最合适的 Actor 来执行任务，不用你自己去翻文档选工具。第三是数据质量。它返回的全是结构化的 JSON 数据，不是一堆乱七八糟的网页源码，拿到手就能直接用。最后是场景覆盖。项目里预置了 12 个 Skill，竞品分析、品牌监控、趋势追踪这些常见需求基本都能搞定。如果你还在为怎么让 Agent 高效抓取网页信息发愁，真的可以试试这个项目。仓库地址：github.com/apify/agent-skills#科技先锋官# #How I AI#

109. 一个不错的Agent教程：《从零开始构建智能体》——从零开始的智能体原理与实践教程本教程旨在带领大家深入理解并构建真正的 AI Native Agent。教程将带领你穿透框架表象，从智能体的核心原理出发，深入其核心架构，理解其经典范式，并最终亲手构建起属于自己的多智能体应用。访问：github.com/datawhalechina/hello-agents #ai创造营# #程序员#

110. openclaw 飞书多agent协作怎么玩？

111. 网页链接“2025 年末，LangChain发布了一份重磅行业报告——《State of Agent Engineering》。这份基于 1340 份问卷调研的报告，揭示了 Agent 生产化过程中的真实挑战、最佳实践和行业趋势。总体来说，Agent 已从实验走向生产，但质量、延迟、安全仍是三大主要挑战，可观测性和评估体系是交付可靠 Agent 的基础。本文将深度解读这份报告，为技术决策者提供可操作的行动指南。”

112. 有哪些搭建agent的框架是必须掌握的？

113. 第3期 | 1分钟让你成为朋友圈最懂AI的人！ Workflow、Agent、智能体集群…这些词天天见，但你真懂了吗？不懂底层逻辑，怎么看懂《十五五规划》里的万亿机会？🚀 今天把AI的底层逻辑一次盘明白，特别是最后那个“一人公司”架构，看完直呼牛！ AI的4个层级，让你超越80%的人更懂AI逻辑。 #AI #人工智能 #清华 #干货分享 #工作流

114. 开源 Agent workforce 项目对比

115. 还在为 Agent 开发头秃？这个开源框架 5 分钟帮你搞定！

116. 2026年GitHub最火爆AI Agent项目

117. 82个AI智能体组团！2天斩获1万星

118. 2026年了，GitHub 日榜告诉我们 AI 时代的开发者在卷什么

119. 【2026-03-18】GitHub今日热门

120. GitHub 热榜项目 - 日榜(2026-02-22)

121. GitHub 热榜项目 - 日榜(2026-03-11)

122. GitHub 热榜项目 - 日榜(2026-02-12)

123. GitHub 本周最火 10 大项目

124. GitHub 热榜项目 - 日榜(2026-03-05)

125. GitHub 热榜项目 - 日榜(2026-02-19)

126. GitHub 热榜项目 - 日榜(2026-03-10)

127. AI 智能体（Agent）的开发框架

128. AI 智能体的开发框架

129. SuperPowers 9万星！AI Agent技能框架爆火GitHub

130. 2026年十大Agent框架纵览

131. AI 智能体的开发

132. 通义千问AgentScope1.0上新，新增开源智能体

133. 《AI Agent 智能体技术发展报告2026》

134. 多智能体框架调研

135. AI Agent 开源矩阵爆火

136. OpenClaw能开箱即用了！附一手体验

137. 别再被Agent架构吓坏了！20行代码手搓Coding Agent，这才是程序员该有的效率【开源】

138. 告别繁琐配置！LangChain 官方发布 Deep Agents

139. 太香了！京东开源AI Agent神器，开箱即用

140. ArkClaw 评测

141. GitHub一巡！解决AI代理开发复杂难题，LangChain DeepAgents提供开箱即用工具集，快速构建生产级智能代理

142. GitHub爆火5万星

143. Agent框架让AI自己写代码，比实习生还靠谱！

144. 🤖 新手必看！2026年最适合初学者的AI Agent工具全攻略(直接抄作业)

145. 熬夜写了个Agent，开源了🌱。

146. Mini Agent

147. 终于等到一款原生面向 SLMs 的 Agentic Framework

148. 智领 Agentic 时代

149. 企业级Agent 平台底座开源，面向企业，一站式Agent开发平台，快速开发企业Agent应用

150. 数据分析Agent开源

151. Agent搭建框架全解析

152. 微软Agent Framework全解析

153. Agent应用生态与技术架构（2025）

154. OpenClaw 多 Agent 协作

155. 我用 OpenClaw 搭建了 10 个 AI 助理团队

156. 智能体｜Agent Tool Use 技术演进路线

157. 2026 年轻量级 AI Agent

158. 2025智能体（Agent）框架汇总

159. Nanobot 代码分析

160. 20260312 GitHub 24 小时纯新 AI Agent TOP5，全是今天刚上，复制即用

161. 云顶轻量级Agent破解高校业务场景AI落地难题!开启智能速办新时代

162. 实测｜MiniMax Agent 本地化部署全攻略，低显存也能跑

163. 深度解析

164. 微软Agent Framework深度解析

165. Agent记忆系统: Letta vs Mem0 vs Zep vs Cognee

166. 告别 AI Agent 部署乱象！AgentBox 来了

167. OpenClaw 是什么 — 一个 AI Agent 操作系统的架构全景

168. OpenClaw橙皮书—从入门到精通

169. OpenClaw与国内同类AI Agent对比｜端侧Agent选型指南2026

170. 最好用的开源AI智能体（Agent）开发框架对比

171. 8大主流AI Agent框架全方位对比分析，助你快速选型避坑！

172. 5大热门AI Agent框架优缺点对比

173. 当我用讯飞开源的星辰Agent后，我发现企业级智能体的门槛被彻底拉平了！

174. 在本地部署了一套超轻量的 Agent 工作流工具

175. AI Agent 及主流 Agent 框架介绍（一）

176. OoderAgent 相比主流Agent框架的五大核心独特优势

177. 告别踩坑！17 款 AI Agent 框架对比

178. 2026年AI Agent深度评测

179. 2026 年 AI Agent 三个值得重点关注的开源项目

180. 构建你的AI梦之队

181. 主流AI Agent框架深度对比与选型指南 (LangChain vs. LangGraph vs. CrewAI vs. AutoGen vs. Semantic Kernel, 2026)

182. 五大必知的 AI Agent 框架

183. AI Agent Teams

184. 建议去 GitHub 学这 6 个项目，打破 Agent 的信息差。

185. GitHub Star数最高的3个AI Agent开源项目，帮你从入门到精通（建议收藏）

186. AI Weekly 001 | 开源项目与科技进展

187. 8大主流 AI Agent 框架测评！企业&开发者选型不踩坑

188. 17个主流 Agent 框架快速对比

189. 【开源】Agents 是一个面向 Claude Code 的多智能体自动化框架，由开发者 wshobson 开源。该项目通过插件化架构组织大量 AI 专家代理，让不同领域的 Agent 协同完成软件开发、运维、测试等复杂任务。开发者可以按需安装插件，从而为 Claude Code 构建一个可扩展的 AI 开发团队。特点 • 大规模 Agent 生态：包含约 100+ 专家级 AI agents 和 70+ 插件模块 • 插件化架构：每个插件只加载所需 agent、工具与技能，减少 token 消耗 • 多 Agent 协作：支持多智能体并行完成复杂任务与开发流程 • 工作流编排：内置 15+ workflow orchestrators 管理复杂操作 • 技能系统：100+ 专业技能包按需加载，实现渐进式知识调用 • 开发工具集成：提供代码生成、测试自动化、安全扫描等工具库名 wshobson/agents

190. 任意Agent皆可强化学习！微软推出Agent Lightning框架，无需修改任何代码

191. 一文详解产品经理必懂的7种AI Agent产品形态：对话agent， RAGagent，工具调用agent，工作流agent，

192. GitHub 榜首项目刷屏：作者把 55 个 AI Agent 人格全部开源了

193. 60k+ 开源项目首选！AGENTS.md：AI 编码 Agent 的标准化操作手册

194. GitHub 上 Star 数量前 18 的开源 AI Agent 项目

195. Hello-Agents项目笔记（7）

196. 一个人 vs 一个AI团队：Agency Agents 让你拥有 9 个部门

197. 2026年 GitHub 最火的 AI Agent 项目TOP5

198. 简单上手Strands Agents，即刻开启AI Agent构建之旅

199. arXiv 2026｜APEX–Agents：一个可即插即用的真实世界Agent评测框架，逼近专业工作场景

200. 智能体｜Agent 自动化评测系统构建

201. 我们的 GUI Agent 开源了：OMG-Agent，AI 手机我来了

202. 受够了给 AI Agent 配环境？这个开源的“技能严选社区”让你开箱即用

203. 基于DeepAgents开发的运维智能体Agent

204. OpenClaw多Agent，这个文件最需要亲自写

205. GitHub 热榜项目 - 日榜(2026-02-21)

206. 一个人太忙？那就让智能体组个团队！零基础入门LangChain V1.0多智能体系统

207. 万字详解7大主流AI Agent开发框架！ AI Agent 作为具备自主行为能力的智能体，其系统架构设计对功能实现与性能表现至关重要。本文基于 LLM 的AI Agent系统架构设计，分四部分展开。 . 📍系统架构系统架构，有三层。工具层像个采购员，从外面的 API、数据库啥的拿数据；推理层是大脑，用大模型琢磨下一步该干啥；行动层就是跑腿的，协调模型和外部工具，还负责跟用户打交道。干活时先定个目标，模型从给的一堆功能里选合适的用，最好有个 “结束” 按钮，告诉系统啥时候完事。 . 🗂️模块化模块化，就像把大公司拆成小部门，每个子智能体各管一摊，比如管退货的、管订单的。上面有个父智能体派活儿，这样就不会像以前那样，指令又长又乱，功能列表也臃肿，系统会更靠谱，谁该干啥也清楚。 . 🎯智能体间互动父智能体通过特定方式把任务分给子智能体，子智能体干完了按统一格式回话。要是搞不定，就喊 “升级”，父智能体再决定是换个智能体试试，还是找人工来弄。 . 🧬数据和 RAG RAG 就是先从外面找相关信息，丰富一下用户的问题，再让模型出答案。结构化数据靠 API 就行，OpenAPI 还能帮大忙；像 PDF 这类非结构化数据，就用向量数据库，把文字转成特殊向量方便搜索，还有个专门的流程处理这些数据，让系统更准更快。#大模型 #大语言模型 #Agent #大模型入门 #大模型技术

208. 挑选和改进智能体框架的实用工具

209. OpenClaw 多机器人多 Agent 模式：打造你的 AI 助手团队

210. 2026：如何利用 AI Agent 重构自动化测试技术体系

211. 开源AI Agent工具合集：从OpenClaw到AutoClaw的技术选型

212. LangChain DeepAgents、Openclaw及claude Agent Skills生态比较

213. 使用 Microsoft Agent Framework实现 Agent 会话持久化

214. OpenClaw-CN：把开源 AI 助手“落地到中国环境”的本地化版本

215. .NET+AI | Agent | Agent as Function (14)

216. Agency Agents开源专家角色库！OpenClaw+系统提示词让AI变身专业团队 11部门全覆盖 9款工具一键安装

217. OpenClaw 搭建「AI 员工团队」：多 Agent 配置实战

218. AI 智能体（Agent）开发框架

219. 3 个 AI 同时在线却互不干扰？OpenClaw 多 Agent 架构完全指南！

220. Microsoft Agent Framework - Agent 调用工具 (Function Call)

221. AI研究：Agent及其主流框架算力要求是什么？

222. GitHub今日最热10大开源项目

223. 【北京信息科技大学】企业级智能体开源系统方案

GitHub星数最高的开源Agent，本地部署成功率却垫底？

精选参考来源