Sub-Agents架构上下文丢失率反超Agent Teams 37%，任务协作模式选错才是AI系统失效的根源_服务软件

1. 云小二 Aivis 的架构实践——基于上下文工程与多智能体的自主服务新形态

2. 企业专属 Agent 开发实践

3. 吴恩达DeepLearning AI 新课程：Design, Develop, and Deploy Multi-Agent Systems with CrewAI可以浏览器装一个沉浸式翻译插件，实时英文字幕转中文。主要介绍了如何设计、开发与部署多智能体（multi-agent）系统，重点在于掌握代理式 AI 工作流（agentic AI workflows）的思维方式与工程方法。将学会如何把复杂任务分解成由多个专门智能体协作完成的子任务，从而高效构建复杂的 AI 应用。1. 掌握构建多智能体系统的基本概念：agent、task、crew、flow、state 等。2. 理解智能体的核心组成：记忆（memory）、工具（tools）、模型上下文协议（MCP）、执行钩子（execution hooks）与防护机制（guardrails）。3. 学会通过 CrewAI 框架将这些要素组合，构建具有可观测性、可控性与可扩展性的系统。4. 了解如何通过指标（metrics）与人类反馈（human feedback）对智能体进行评估与持续改进。访问：learn.deeplearning.ai/courses/design-develop-and-deploy-multi-agent-systems-with-crewai

4. AI时代，最不值钱的，就是重复劳动；最值钱的，是你得熟练指挥智能体。#大咖观察 #红衣聊AI #硅谷 #智能体 #AI应用

5. 今年最火的开源Agent项目，如何思考Agent的自我进化？

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

7. 【越复杂越容易崩：AI创业者用25个项目学到的教训】快速阅读：构建过25个以上AI Agent的开发者发现，真正稳定挣钱的项目几乎都是“一个API调用+一个好Prompt”的极简结构。复杂的多Agent系统看起来很厉害，实际上每增加一个Agent就多一个崩溃点，每次Agent之间的交接就是一次信息损耗。---有人在Reddit发帖引发广泛讨论：做了25个以上AI Agent，最后发现最能稳定挣钱的几个，简单到说出来都嫌丢人。邮件自动写入CRM，一个Agent，每月$200，从不报错。招聘简历解析，每个席位$50，一个Prompt搞定。FAQ支持机器人，零编排。全是这种东西。没有Agent之间互相开会，没有主管Agent统筹协调，没有什么记忆管道。他总结了一条核心规则：每增加一个Agent，就多一个故障点；每次交接，就是上下文死亡一次。这个判断有网友补充得更精确：Agent A知道自己为什么做这个决定，Agent B只拿到输出，不知道原因。到了Agent C，你在玩传话游戏。五个Agent串成链，原始信息里的细节和语境，基本已经被“电话游戏”掉了。有人做过一个具体实验：三个图像识别Agent并联跑，比单Agent准确率高了2%，但token消耗是三倍。串联跑，每次交接误差叠加，最后准确率反而掉了30%。也有网友指出，把它叫做“Agent”还是“自动化流水线”，其实是个概念问题。有人认为，没有真正自主决策的系统，只是“带LLM节点的工作流”，算不上Agent。帖子作者的回应相当直接：叫什么不重要，客户付钱是因为问题被解决了，不是因为架构名词好听。反驳者说，用户完全可以自己用Claude搭同样的东西。作者说，这个逻辑适用于所有服务行业，YouTube上有水管教程，水管工照样存在。他的客户是运营经理、招聘专员、物流协调员，不是技术创始人。技术上可行和商业上可靠运行之间的那段距离，才是服务的价值所在。有观点认为，Prompt本身是商品，关系和可靠性才是人们真正付钱的东西。有人见过别人用一个他两小时能复刻的工作流收$500/月，原因只是那个人拥有细分市场、完善的新用户引导和用户信任。有一条留言的锐度让人印象深刻：那些在演示视频里看起来很厉害的复杂多Agent系统，通常在60天内就被替换掉了。而那些无聊的单Agent，挣着钱，没人关注。“一个Agent，一个任务，可衡量的输出。”这个判断其实也有边界。真正需要并行处理、子任务彼此独立的场景，多Agent的设计是合理的。但问题在于，大部分人在还没验证简单版本能不能用的时候，就已经开始搭复杂系统了。最后有人补了一句：多Agent系统最吸引人的地方，恰恰是它会让你感觉自己在做严肃的工程。这通常只是严肃的过度工程。ref: www.reddit.com/r/AI_Agents/comments/1s1o0k6/25_agents_built_heres_the_uncomfortable_truth#AI创造营##人工智能#

8. 终于，清华团队养出一只能「断网干活龙虾」！两栖版智能体杀疯了

9. 如何在短时间内学习Multi-Agent（有翻译成智能体or代理）建模?

10. TRAE中国版白送SOLO，一人指挥一支AI大军重磅消息！SOLO终于上线TRAE中国版了，Waitlist免费开放中本期视频实测TRAE的新版本，亮点很多 1、先规划再动手的 Plan 模式 2、带专家团一起干活的 Subagent 子智能体 3、DiffView 差异视图 4、多任务并行 5、上下文智能压缩长时运行不掉链子 SOLO终于把AI从“瞎干活的外包”变成了“懂协作的队友” #AI #人工智能 #TRAE #AI编程 #vibecoding

11. 你还在用旧思维与AI打交道吗？ #大咖观察 #红衣聊AI #AI时代 #智能体 #大模型

12. 深度｜养马、养虾、练模型：MiniMax 的 Agent 三线布局到底在赌什么？

13. Harness Engineering：AI Agent 落地企业的工程化核心

14. 未来的人和智能体应该是相互融合协作的关系。 #大咖观察 #红衣聊AI #智能体 #人机协作

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

16. 都有这么多 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创造营# #程序员#

17. 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# #程序员#

18. AI 智能体驾驭 (Harness) 工程的兴起

19. 一个挺有意思的项目，值得体验一下：ClawTeam-OpenClawGitHub：网页链接如果你已经在用 OpenClaw / Claude Code / Codex / Hermes 这类 CLI Agent，应该会秒懂它的价值——它不是单纯再造一个 Agent，而是让一个 Agent 可以继续拉起多个 Agent 一起干活。比如你只给一个目标：“做一个 Web App”然后它可以自己拆任务、拉 worker、分工开发、同步进度、最后汇总结果。我觉得它最有意思的点有几个：默认深度适配 OpenClaw，不是顺手兼容一下，而是真正往 OpenClaw 工作流里嵌多 Agent 协作更工程化：任务拆分、会话隔离、结果汇总，不再全靠人盯着支持多种 CLI Agent：OpenClaw、Claude Code、Codex、Hermes、Cursor 等说白了，以前大家用 AI coding agent，很多时候还是“一个人单兵作战”；这个项目想推进的是：把 AI 编码从单兵模式，推到小团队协同模式。#OpenClaw# #AI编程# #多智能体# #AIAgent# #ClaudeCode# #Codex#

20. 智能体，正在决定企业的生死？ #大有学问 #红衣聊AI #智能体 #AI工具

21. 从“聪明的废物”到“数字员工”，智能体落地如何破局

22. 这个对 Agent 的定义和归纳挺好！Agent 是一种能够自主决策、执行任务、并在过程中动态调整行为的智能体。它并不是简单的问答系统，而是能理解目标、规划行动、调用工具、记忆状态，并根据反馈优化策略的智能执行系统。关键特征：（1）自主性：Agent 不依赖固定流程，而是根据上下文和已学到的信息动态决定下一步行动。（2）记忆能力：能够在多轮交互中保持状态，记住过往的操作与结果，用以改进后续决策。（3）工具使用：可以选择并组合不同的外部工具或系统，灵活完成复杂任务。（4）自适应性：在策略失败或信息不足时，能尝试不同方法或补充信息，持续优化执行路径。架构形式：（1）单智能体（Single-Agent）架构：由一个 Agent 处理所有任务，适用于中等复杂度的流程。（2）多智能体（Multi-Agent）架构：不同的 Agent 负责不同子任务，能处理复杂工作流，但需要协调机制确保协同一致。工作方式：Agent 通常会将用户请求拆解为子任务，通过搜索、记忆和工具调用等过程生成最终响应，并在此过程中不断判断是否需要更多信息、是否已回答过类似问题、是否需要切换策略。归纳起来：Agent 是具备理解、规划、执行、记忆与自我调整能力的智能体，能够以动态和自适应的方式完成复杂任务。#ai创造营# #程序员#

23. OpenAI 如何打造AI原生工程团队的最佳实践《Building an AI-native engineering team》，归纳如下。文档介绍了团队应该如何真正把 AI 智能体嵌入工程体系，从计划、设计、开发、测试到上线运维形成闭环，加速整个 SDLC（软件开发生命周期）。1. 规划（Plan）规划往往需要大量代码语境理解，过去必须依赖资深工程师反复澄清。文档强调可以先让智能体读取需求、遍历代码库、标记模糊点、拆分工作项，把早期对齐成本显著降低。团队应该做的是专注决策、风险判断与优先级。因此，智能体不止是“辅助写代码”，而是可以提前介入需求—代码映射，用它来减少来回沟通。2. 设计（Design)设计通常被大量样板工作拖慢，例如项目结构初始化、组件框架搭建、样式规范套入。文档强调应让代理完成“从设计 → 组件 → 代码”的流水线式生成，再由工程师审阅架构一致性和 UX 合理性。设计阶段不是用 AI 画原型，而是让智能体直接产出“可运行验证的版本”，显著减少返工。3. 构建（Build）这是 AI 代理提升最明显的阶段。文档给出的最佳姿势，是让智能体负责端到端的初稿实现，包括模型、API、UI、测试和文档，工程师则把精力转向性能、架构、长期可维护性。构建阶段应把 AI 视为“第一实施者”。工程师不再负责逐行写，而负责判断生成方案是否符合系统演进方向。4. 测试（Test）随着智能体承担更多实施工作，测试反而成为工程师控制质量的主轴。最佳实践是让智能体生成测试用例、补全边界场景，并在代码变更后更新测试。不要只让智能体写代码，要让它写测试、跑测试、基于失败结果迭代；测试越强，智能体越可靠。5. 代码审查（Review）智能体可以持续、稳定地进行第一遍代码审查，尤其擅长发现逻辑漏洞、竞态、错误的数据库访问方式等。工程师则聚焦架构一致性与复杂变更的判断。AI 审查不是为了“更快合并”，而是为了“减少重大缺陷进入主干分支”。工程师的关注点应从细节检查转为整体正确性。6. 文档与知识沉淀（Document）智能体非常擅长根据代码生成结构化说明、依赖图和变化总结。最佳做法是把文档维护接入流水线，例如在发布流程中让智能体自动产出变更摘要，并由工程师确认关键部分。把文档写作视为“可自动化的持续任务”，而不是阶段性集中补齐。7. 部署与运维（Deploy & Maintain）让智能体读取日志、Trace、部署记录，再结合代码自动定位可能问题，并给出可行修复。工程师负责判断、确认和实施关键决策。在运维中使用智能体的关键不是预测故障，而是让其整合多源上下文，减少人工排查时间。重点：团队角色的重定义文档贯穿始终的主题是三个动词：Delegate、Review、Own。1 工程师应把重复性、结构化的工作交给智能体。2 工程师需要对智能体产出进行审阅，但专注关键决策点。3 工程师必须对系统的长期演进负责，对所有上线内容最终背书。AI-native 团队不是“工程师被取代”，而是“工程师从执行者变成决策者与架构塑造者”。#微博兴趣创作计划##人工智能#

24. Gaurav Sen提出，AI Agents最终会像微服务一样“淡出舞台”。它们部署复杂、难以扩展，终会被隐藏在完善的工程方案背后。炒作无法承受复杂性的考验。不少业内人士对此观点展开讨论：- 微服务并未消失，而是“成长”为基础设施，背后支撑着Netflix、Uber等巨头，AI Agents也会经历类似路径：从爆炒到失败，再到成熟、隐形，最终无处不在却不再被特别提及。- AI Agents的价值不在于表面光鲜，而在于背后的基础架构和标准化的工具链，真正的赢家是构建可靠运行环境的公司。- 复杂性是挑战，但随着工具完善，部署会更简单。AI Agents不会消失，只会“隐形”成产品的一部分，用户感知不到它们的存在。- 微服务的痛点在于增加了复杂度，而好的系统应该追求简单易用。AI Agents的未来也需避免这一陷阱。- AI Agents作为“劳动力替代”技术，潜力巨大，企业愿意投入巨资解决复杂度，因为它们关系到“替代人工成本”的核心利益。- 技术炒作终将消退，留下的是稳健、可靠的技术基础。AI Agents不会消失，而是成为未来数字基础设施的重要组成。AI Agents正处于从“炫技”到“落地”的必经阶段。它们不会因为难以扩展而消亡，而是通过不断成熟，变成无处不在却不张扬的幕后力量。未来的竞争，是基础设施和工具链的竞争，真正的价值在于解决复杂性并实现稳定可靠的规模化应用。原文：x.com/gkcs_/status/1993363141049123007

25. OpenClaw 搭团队太折腾？这个 Skill 一键搞定多智能体协作

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

27. 智能体社交革命：AI Agent是怎么来到你我身边的？【硅谷101】

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

29. 如何成为世界一流的智能体工程师

30. 这篇文章《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创造营# #程序员# 黄建同学的微博视频

31. 今天 GitHub 的 Trending 被 Agent 类项目集体占领了，星标涨得最猛的五个项目全部跟 AI Agent 相关。逐个拆解一下。涨得最凶的是 NousResearch 的 hermes-agent，24 小时新增 8800 星。它要解决的是 Agent 领域一个老大难问题：没有记忆。传统 Agent 每次对话都是从零开始，上一轮聊过什么全忘了。hermes-agent 做了一套动态 patch 机制，让 Agent 能够持续积累对你的了解，用得越久越懂你的习惯和偏好。相当于给 Agent 装了一个可以自我进化的长期记忆系统。项目地址：http://t.cn/AXVpXePA 第二个是 TauricResearch 的 TradingAgents，24 小时新增 3900 星。思路很有意思，它用多个 Agent 模拟了一家完整的交易公司。有专门负责挖数据的研究员 Agent，有负责风控的 Agent，还有最终拍板的决策者 Agent。这些 Agent 之间会互相质疑、辩论，充分博弈之后才会下单。比起单个 Agent 拍脑袋做决策，这种多角色对抗的方式能有效降低冲动交易的风险。项目地址：http://t.cn/A6exS2vB 第三个是 SakanaAI 的 AI-Scientist-v2，24 小时新增 2000 星。这个项目更硬核，做的是全自动科研 Agent。基于 agentic tree search 驱动，能自己提出假设、设计实验、跑实验、分析结果，最后还能把论文写出来。一套流程走下来，一个 Agent 能顶一个小型实验室的产出。对科研效率的冲击是实实在在的。项目地址：http://t.cn/A6r9nT3h 第四个是微软官方出的 agent-framework，24 小时新增 1800 星。这是一个 Agent 编排框架，同时支持 Python 和 .NET，可以快速搭建和部署多 Agent 工作流。以前要实现类似的功能，很多人得靠 LangChain 加上一堆胶水代码硬拼，现在微软直接给了一套标准化的解决方案，从搭建到生产部署都覆盖了。项目地址：http://t.cn/AX7Y6Qr3 第五个是 Block 公司的 goose，24 小时新增 1500 星。它是一个开源的可扩展 AI Agent，定位比代码补全工具更进一步。它能自主完成安装依赖、执行脚本、编辑文件、运行测试这些完整的开发流程，基本上你给它一个任务描述，它自己跑完全程。项目地址：http://t.cn/A638oT2O 整体来看，这五个项目覆盖了 Agent 发展的几个关键方向：记忆与自我进化、多 Agent 协作与博弈、自动化科研、标准化编排框架、以及端到端的任务执行。Agent 正在从单点工具向系统化能力演进，这个趋势在今天的 GitHub 榜单上体现得非常明显。 #How I AI##科技先锋官#

32. AI Agent 的工作原理和架构是什么？

33. OpenClaw 是什么？一文看懂它的架构与核心模块

34. 构建专业智能体：从通用 AI 到企业级应用的工程化实践

35. 打通智能体孤岛：用 AgentRun 构建生产级 A2A 多 Agent 管理协作系统

36. 聊着天把虾队管了：用 HiClaw 正确打开多智能体协作方式【限时领 PPT】

37. 魏牌V9X凭什么敢卖50万？AI接入车子的新体验… #认人识人是AI智能体的照妖镜#魏建军变装实测汽车AI智能体

38. AI智能体时代，职场规则已不同以往。想成为赢家，关键在于找准自己的位置。#大咖观察 #红衣聊AI #智能体

39. 太爽了！Hermes Agent 发布UI了，本地对接最强开源 Gemma 4 模型+ 微信（免费无需Token）| 零度解说

40. 看看 Claude Code 怎么做 Harness，这才是 Agent 工程化的真正难点

41. 让AI智能体拥有像人类的持久记忆：基于LangGraph的长短期记忆管理实践指南网页链接如何让AI智能体（Agent）像人类一样拥有持久的记忆，从而在复杂的连续任务中保持上下文感知和深度理解？这已成为构建高级智能体的核心挑战。本文将深入探讨Agent Memory的核心概念，并聚焦于LangGraph框架下的长短期记忆实现，详解短期会话与长期知识的存储、管理、语义检索等技巧。更进一步地，我们将通过一个引入MCP协议的实战案例，手把手带你构建一个真实的融合长记忆机制的Multi-Agent系统，直观展示中断、记忆与协作的融合。

42. 基于多 Agent 协作的智能营销闭环：洞察、触达与转化

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

44. 【无广】我用AI Agent手搓了一个科技博主神器：动态图表生成器！

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

46. 利用300个Agent！从零开始搭建独属于你的AI公司/团队

47. Claude Code被扒了底裤之后，我们就能更好地了解其技术架构了。这个教程通过解读 Claude Code 的源码架构，带你从零理解构建一个 Code Agent 的全部关键技术。访问：github.com/jiji262/build-code-agent#HOW I AI# #程序员#

48. 推荐吕鹏（@甩甩鸟哥很严肃）开源的 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 网页链接

49. 组织本身要成为「可计算代码」了？！1. 什么是智能体组织（Agentic Organization）？你了解什么是智能体组织吗？智能体组织看似新潮，但其实在触及组织管理的本质问题——组织中自主决策和信息流动的本质。1）传统定义：一个组织由人组成，通过等级制、流程、制度来协调众多个体的行动。2）智能体组织的定义：一个组织由「人+AI Agent混合体」组成，通过分布式自主决策和实时反馈来优化整体目标。关键区别在这里：1）传统公司：人做决策，决策流动形成信息链，从CEO→部门→执行层2）智能体组织：Agent做决策，Agent之间通过协议（非层级）交互，形成决策网络这不是自动化的升级，而是组织结构本身的范式转变。2. 为什么传统公司本质上是低效的？传统公司的低效来自三个根本缺陷：1）信息延迟和失真一个CEO要做战略决策，需要的信息来自：数据部门→分析师→部门经理→VP→CEO。每一层都有信息压缩和解释权。CEO拿到的信息，已经被人为过滤七八次。数学上讲，这是一个指数衰减的信息流。假设每层信息保留度是80%，经过7层后，CEO拿到的信息保留度只有0.8^7 = 21%。也就是说，CEO做决策时，只基于原始信息的1/5。智能体组织里，数据直接流向Agent，Agent基于完整信息做决策。信息流变成了常数而不是指数衰减。2）知识孤岛营销部和工程部各有各的工作流和隐性知识。营销知道什么样的用户容易转化，工程知道什么样的架构容易维护，但两个知识很难交汇。为什么？因为跨部门对话的成本太高了——开会、邮件、官僚流程。所以大多数500人的公司，真正在创意工作上的人可能只有5%。3）决策周期长从识别问题→汇报→批准→执行，通常需要2-4周。而竞争发生在毫秒级别。这意味着传统公司永远比市场慢一拍。智能体组织的Agent可以秒级做决策（当然要有清晰的目标和约束）。3. 智能体组织的核心机制是什么？不是AI替代人，而是「决策权的分布式转移」。新的组织架构三元素：1）面向智能体Agent的架构传统：金字塔。信息上升，指令下降智能体：网格/编队。Agent之间通过协议而非报告关系交互具体例子：- 营销Agent知道今天转化率下降- 工程Agent知道今天部署了新的推荐算法两个Agent能自主协商这是否相关，而不需要人工干预这背后的理论是Game Theory——多个自主体在约束条件下博弈，寻求纳什均衡（Nash Equilibrium）。McKinsey的研究指出，智能体组织本质上是应用博弈论的组织设计。2）Org Code（可计算的组织代码）Karpathy说：所有的组织习惯和流程，都是Org Code。传统公司：我们的决策流程是这样的（人工、缓慢、隐性）智能体组织：我们的Org Code是这样的（可编程、透明、可优化）如果组织流程能被写成代码，就能被复制（fork）、优化、和即时调整。这是微观经济学里的制度重构。以前制度是隐性的、刚性的，现在变成了显式的、软件代码一样灵活。3. 治理延迟这是SSRN最近发表的一个关键概念：治理延迟 = Agent执行速度 vs 组织干预速度的时间差。比如：传统公司：Agent做错决策，人发现这个错误需要2周，然后审批修正需要1周 → 总共3周的损失智能体组织：通过预先设计的管理约束，在Agent的决策权限中嵌入约束条件，错误被提前防止，而不是事后修正这背后的理论是Threshold-Based Authority——给Agent设定清晰的决策边界，超过边界自动触发人工审查。4. 为什么这种变化必然到来？从竞争环境变化的角度：过去：竞争基于谁的决策质量更高（需要更聪明的CEO）现在：竞争基于谁的决策速度更快（需要更快的决策系统）这是一个从速度维度到时间维度的转变。在秒级、毫秒级的竞争中，传统组织已经输了。从技术可能性的角度：现在，Claude、GPT-5等模型的能力已经足以支撑Agent做独立决策而不仅仅是推荐。当技术能力和商业需求对齐，转变就不可避免了。5. 智能体组织会面临什么挑战？1）治理延迟的困境Agent执行速度是毫秒，人的干预能力是小时。如何确保Agent做出的决策在规则内正确，但战略上也正确？SSRN论文指出：仅仅遵守规则还不够。一个Agent可以在所有约束下正确决策，但决策的组合可能导致战略目标偏离。这需要更高层的Meta-Governance——对Agent的整体决策模式进行监督，而不仅仅监督单个决策。2）组织 DNA 的重新编写Berkeley的CMR论文指出：智能体组织不是在旧组织上加Agent，而是要从设计阶段就考虑Agent。这意味着：新公司可能比老公司有3-5倍的竞争优势（新生儿vs进化的恐龙）老公司的转型成本极高，因为要改变的不只是流程，而是组织的DNA3）Agent 协作的博弈论陷阱多个Agent在网格结构中交互，本质是多人博弈。如果激励结构设计不当，可能陷入：- 每个Agent都在最优，但整体次优- 搭便车问题- Agent之间的意外冲突McKinsey的「Accountability by Design」强调，必须在Agent的激励机制中，嵌入整体目标优化而不仅仅是个体最优化。6. 智能体组织时代，人的角色是什么？角色转变：- 从做决策的人 → 设计决策系统的人- 从执行计划的人 → 监督Agent编队的人- 从连接信息的人 → 优化信息流的人可能出现的新岗位：- Agent编排师 — 设计Agent的目标、约束、协作协议的人- 混合经理（Hybrid Manager）— 领导人+Agent混合团队，权衡自主和控制- 治理架构师 — 设计Agent间的制约机制，确保没有系统性风险- AI教练 — 帮助传统员工理解如何与Agent协作可能消失的岗位：- 连接点型工作（会议协调、流程对接、信息中转）- 纯执行岗（那些按流程办的工作）这意味着：不是AI替代人，而是人的工作内容彻底改变。适应的人会获得3-5倍的效率提升，不适应的人会被淘汰。7. 总结一下1） Org Code 的可复制性改变了竞争格局传统公司的竞争优势来自经验和人才（都是长期积累）。Agentic公司的竞争优势来自Org Code（可以快速复制和迭代）。这意味着：第一个搞清楚赚钱的Org Code的公司，可以在3个月内复制到全球10个市场。而传统公司需要3年招聘和培训。2）组织变成了可计算的这是历史性的转变：组织首次从人工进化到编程。从人类文明的角度：- 工业革命：体力被机器替代- 信息革命：信息处理被计算机替代- Agentic革命：决策和协调被Agent替代每次都是一个小比例的人掌握新工具，而大多数人被淘汰。这次的速度会是最快的。3）组织管理学的范式转变从科学管理+人力资源到Agent设计+博弈论优化。这意味着：未来的CEO不需要懂人力资源管理，而需要懂智能体架构。组织管理的技能集将完全改写。你准备好了吗？如果你在一个传统组织工作，现在要思考三个问题：1）我的工作，是连接点型还是创意型？如果是前者，你有2-3年的窗口期，赶紧学如何设计智能体系统。如果是后者，你反而更安全，因为创意工作不容易被Agent替代，但你需要学会与Agent协作。2）我的组织，是否已经开始思考Org Code？如果没有，你们的竞争优势在缩小。没有可计算的组织代码，就没有快速迭代和复制的能力。3）在Agentic时代，我的稀缺价值是什么？- 能设计复杂系统的人（Agent Orchestrator）- 能理解博弈论的人（如何激励Agent）- 能做判断和选择的人（AI不能替代的人类直觉）

50. Multi-Agent Collaboration via Evolving Orchestration这篇论文提出了一个极具启发性的多智能体协作框架：让整个多智能体系统由一个可学习的 “木偶师（Puppeteer）” 动态调度所有智能体（Puppets）这个框架，旨在通过解决现有系统固有的静态组织结构问题，来优化大型语言模型（LLM）的多智能体协作。其核心思想是利用一个集中式协调器，像木偶师一样，根据任务的动态变化来动态指导和调度专业化代理的激活顺序。这种协调器通过强化学习进行训练，其奖励函数旨在同时最大化解决方案的质量和计算效率，例如减少令牌消耗。实验结果表明，该方法在各种任务中实现了卓越的性能，同时显著降低了计算开销，证明了其可扩展性。分析进一步揭示，经过优化的协调机制促使多智能体系统形成了更紧凑且具有循环反馈的推理拓扑结构，超越了传统的链式或树状模型。1 研究提出的问题：当前 MAS 存在的根本瓶颈1）当前大多数多智能体系统采用静态结构，例如固定流程、固定 DAG、固定角色协作方式。2）当任务复杂度提升或智能体数量增加时，静态架构会出现协调开销大、冗余调用多、效率下降等问题。3）某些智能体在任务中实际贡献有限，但静态结构依然会触发它们，导致 Token 浪费甚至干扰推理。4）在软件生成、复杂问答、开放域推理这些任务中，多智能体之间真正有效的协作模式往往因任务不同而变化，这很难靠人工预设计完成。因此，论文提出一个关键问题：能否让一个系统自动“学会”如何调度智能体，而不是用固定协作结构？2 核心思想：木偶师式动态调度（Puppeteer Paradigm）智能体是“木偶”，一个中央控制器是“木偶师”，其任务是在推理过程中动态决定谁上场、谁退场。整体架构包含三个关键点：1）让一个中央 orchestrator（木偶师）在每一步根据当前任务状态，选择一个最合适的智能体执行下一步推理。2）这个 orchestrator 会在任务执行后得到奖励（正确性 + 计算成本），并通过强化学习不断优化调度策略。3）虽然过程是序列化的（每步一个 agent），但整个推理轨迹可以折叠成一个动态生成的有向图，即“推理图谱（Graph-of-Thoughts）”。这意味着：1）系统可以随着任务自动形成树结构、图结构、循环结构等多种协作拓扑。2）协作不再依赖预定义流程，而是任务驱动、自适应、持续演化的。3 方法框架详细拆解论文的方法分成两个关键模块：3.1 动态编排（Dynamic Orchestration）1）将每个智能体表示为一个三元组（模型、推理模式、可用工具）。2）将多智能体协作建模为一个集中式决策过程：木偶师在时间 t 根据全局状态 Sₜ 选择一个 agent 执行推理。3）每个 agent 输出结果后更新全局状态，并交由木偶师继续选择下一个 agent。4）当遇到终止条件（例如 Terminator agent）时，系统停止并输出最终结果。这个决策过程严格满足马尔可夫性，天然适合强化学习：P(aₜ₊₁ | S₀, ..., Sₜ₊₁) = P(aₜ₊₁ | Sₜ₊₁)因此 orchestrator 可以真正做到基于实时状态的动态调控。3.2 自适应演化（Adaptive Evolution）论文使用 REINFORCE 算法优化 orchestrator 的策略 π：1）任务完成后一次性给出奖励 r（正确 1，错误 0，开放任务得分区间为 [0,1]）。2）每一步会设定成本 Cₜ（Token 或 FLOPs）。3）总回报为 r 减去 λ·成本，λ 是可调的效率权重。该设计促使 orchestrator 学会：1）更倾向使用高性价比的智能体2）避免冗余推理步骤3）尽快调用 Terminator 停止推理4）长期形成紧凑而高效的协作结构4 实验结果解析：性能提升 + 成本下降“双赢模式”1） Puppeteer 在几乎所有任务上都获得显著性能提升2）强化学习后的 evolved 版本比初始版本显著更强3）在 Titan 模型空间中，平均性能从 0.6893 提升到 0.77314）更重要的是 Token 开销随着训练反而下降，不是上升这与过去多智能体研究经常出现的“调用越多越好”形成鲜明对比。5 拓扑结构的演化：从链式到紧凑循环论文一个非常有趣的发现是：随着 orchestrator 训练，多智能体协作拓扑从松散 → 紧凑，从树结构 → 图结构，并出现大量循环。具体表现为：1）图密度增加2） agent 之间的循环次数增加3）反复调用少量“核心智能体”的情况越来越多4）冗余 agent 被逐步淘汰5）推理链路更短、更集中、更有效其背后的原因非常符合直觉：1）强 agent 往往值得重复调用2）循环（自我检查、跨 agent 校验）有益于复杂推理3）扩散式的树结构容易浪费 token4）强化学习会惩罚冗余推理，鼓励形成高效闭环可以认为，这是一种机器自动学习推理结构的过程，类似于“推理图谱的自组织”。#ai创造营# #科技#

51. 【智能体软件不是提示词堆叠：一场面向 Agent 的系统工程实践】构建智能体软件（Agentic Software）不应仅仅是“提示词工程”的堆叠，而是一场严谨的系统工程实践。Ashpreet Bedi 通过复盘贝尔实验室构建电话网络的历史教训，指出当前 AI 开发中“过度优化局部、忽视系统整体”的误区。+ 真正的智能体软件是“业务逻辑被 Agent 替换”的常规软件，它必须在五个核心层面上实现协同：1. 智能体工程（Agent Engineering）这是系统的“大脑”。除了模型选择，更关键的是定义确定性的执行流、工具配置和上下文管理。智能体的行为在可预测时应保持确定，在不可预测时应保持可观测。2. 数据工程（Data Engineering）上下文即数据。记忆、存储和知识库必须遵循成熟的数据工程原则：设计良好的 Schema、结构化查询以及高效的读写流水线。Agent 的能力上限取决于它获取数据的质量，而非模型参数。3. 安全工程（Security Engineering）安全必须由系统强制执行，而非靠提示词约束。“只读权限”应该是数据库连接层面的配置，而不是告诉 Agent “请不要修改数据”。必须通过 JWT 验证、RBAC（基于角色的访问控制）和请求隔离，防止数据越权。4. 接口工程（Interface Engineering）Agent 会出现在 REST API、Slack、终端等多个表面。挑战在于如何将不同的身份系统（如 Slack 用户 ID 与产品内部 ID）统一映射，确保权限控制在所有入口保持一致。5. 基础设施工程（Infrastructure Engineering）95% 的工作与传统服务无异（容器化、云部署、横向扩展）。剩下的 5% 在于应对 Agent 的特性：更长的请求耗时、流式响应（SSE/WebSockets）以及主动触发的任务。+ 系统工程的实践：Dash 项目为了证明这一理念，Agno 团队开源了 Dash —— 一个具备自我学习能力的 SQL 数据智能体。它展示了系统工程如何解决实际问题：- 六层上下文增强：Dash 不直接写 SQL，而是结合表元数据、业务规则、历史查询模式、机构知识、错误学习记录和运行时 Schema 检查。- 自我进化闭环：当 Agent 执行 SQL 报错时，它会诊断修复并记录“学习心得”。第 100 次查询比第 1 次更准，不是因为模型变强了，而是数据层进化了。- 架构级安全：分析师 Agent 连接的是只读引擎，工程师 Agent 只能写入特定的 dash Schema。这种物理隔离确保了即便模型“幻觉”产生恶意指令，系统也会在底层将其拦截。当我们从系统视角审视软件时，许多争论（如 MCP vs CLI）会变得显而易见。不要给 Agent 不受限的权限，要给它定义清晰、边界明确的工具；不要把记忆存在散乱的文件里，要存入数据库。系统工程不是为了增加复杂性，而是为了让各个组件在交互中产生超越个体的可靠性。x.com/ashpreetbedi/status/2041568919085854847github.com/agno-agi/dash

52. 在研究编程Agent，Agent核心就几十行代码，那剩下的几万行到底在解决什么问题？

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

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

55. 观察 AIRI 源码：一个 Agent 系统如何处理入口、扩展与执行闭环

56. P99延迟降72%、成本降83%！字节跳动Agent上下文平台首度公开

57. 从能聊天的大模型，到会干活的智能体，AI正迎来全新进化。企业AI落地的机会就藏在这里。#网络名人赞两会 #2026全国两会 #红衣聊AI #产业升级

58. AI智能体也卷起来了？又懂业务又不用搭工作流…

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

60. 上个月，谷歌悄然发布了五篇关于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

61. Deep Agents：LangChain开源的Agent框架，开箱即用的LLM应用方案。核心思想：给你一个开箱即用的Agent，需要定制再加工。Deep Agents基于LangGraph构建，内置了单Agent应用的标配能力：任务规划、文件系统访问、Shell执行、子Agent委托、自动上下文管理。会话长了自动总结，大输出存文件，子Agent有隔离的上下文窗口。启动简单，支持任何能调工具的LLM（OpenAI、Claude、开源模型都行）。需要时加工具、换模型、调提示词。支持MCP。对比其他框架：1.LangGraph：底层编排框架，基于图和状态机。完全可控，支持流式、持久化、断点恢复。缺点是学习曲线陡，小任务过度设计。2. CrewAI：多Agent协作框架，建在LangChain和LangGraph之上。提供Agent、Task、Crew等高级抽象，快速定义多Agent分工。优点是上手快，缺点是多Agent固定模式，非标准行为定制困难。3. AutoGen（Microsoft）：事件驱动，支持conversation-based Agent交互和group chat。v0.4引入强可观测性和异步模型。适合多Agent对话，不适合需要持久化和复杂状态的应用。4. Deep Agents的位置：单Agent框架，高于简单的ReAct（思维链+工具调用），低于多Agent系统。填补了这个缝隙：需要快速上手，但又要求工业级的规划、文件访问、子Agent能力。技术特点：1. Deep Agents采用trust-the-LLM模型——Agent可以做工具允许的任何事，安全边界由工具和沙箱保证。这套思路来自Claude Code，也就是LangChain在把Claude Code的经验系统化。2. 上下文管理做得细致：会话自动总结、大输出转文件、子Agent隔离上下文窗口。处理长期运行任务（爬虫、研究、报告生成）时能显著降低token消耗。应用场景1. 快速原型或一次性脚本 → Deep Agents足够2. 复杂单Agent任务（爬虫、研究、代码生成） → Deep Agents很合适3. 多Agent协作 → CrewAI更顺手4. 需要完全自定义Agent行为 → LangGraph完全控制5. 对话式多Agent互动 → AutoGen更原生项目：github.com/langchain-ai/deepagents#HOW I AI# #程序员#

62. 对话 Synergy 团队：「龙虾」之后，下一代智能体正演变为「互联网公民」

63. 【拆解 AI 协作逻辑：Sub-Agents 与 Agent Teams 核心差异】快速阅读：多数人面对复杂任务时会惯性地堆砌多个 Agent，这往往是错误的。设计的核心不在于 Agent 的数量，而在于任务所需的协作模式：是需要隔离执行的 Sub-Agents，还是需要实时通信的 Agent Teams。目前的 AI 系统构建方式大多存在误区，当任务变得复杂，人们倾向于直接套用多智能体架构，但这其实是在增加不必要的系统开销。Sub-Agents 更像是函数调用。它是一个被高度隔离的实例，拥有独立的系统提示词、工具集和上下文。它只负责把混乱的探索过程压缩成一个干净的信号返回给父级。这种模式追求的是并行与隔离，Sub-Agents 之间无法直接对话，也不能互相创建新实例。这就像是把任务分发给不同的专业外包，你只关心结果，不关心过程。Agent Teams 则更像是一个动态运行的操作系统。它们强调协作，通过共享任务层和实时通信来同步状态。一个前端 Agent 发现变动，可以立刻通知后端 Agent。这种模式是持久且具有交互性的。很多人习惯按角色拆分，比如规划者、开发者、测试者。有观点认为，这种做法会导致严重的上下文丢失。执行者不知道规划者的初衷，测试者也不了解执行者的决策细节。每一次交接都是一次信息熵增。真正有效的拆分逻辑应该是基于上下文边界的。如果两个任务共享深层的背景信息，就把它们留在同一个 Agent 里。只有当上下文可以被干净地剥离时，才进行拆分。设计时可以参考这五种模式：提示词链、路由、并行化、编排者-执行者、以及评估者-优化者。如果任务本身很简单，或者 Agent 之间存在极强的依赖关系，强行引入多智能体反而会因为协调开销过大而导致系统崩溃。与其思考需要多少个 Agent，不如问问：这个任务到底需要什么样的协调？x.com/Suryanshti777/status/2047694444787577236

64. 智能体上下文工程：为什么文件系统成了AI记忆的最佳载体？

65. 在线开发自动化调试和迭代代码的朋友们注意了！autoagent（网页链接）致力于打造“自主引擎工程”。autoagent的核心思想是：你不再直接改动运行代码，而是通过编写一份program.md指令文件，让一个meta-agent自主读取、修改和优化agent.py中的代码，实现自动构建和迭代agent。它会根据benchmark任务的得分，自动调整策略，类似AI自动“打怪升级”的过程。项目亮点：- 单文件Python架构，注册驱动，结构清晰易改；- 任务基于Harbor格式，方便统一测试；- 整合Docker隔离环境，安全无风险地自动跑任务；- 自动根据测试得分保留更优改动，实现闭环优化；- 支持并行任务运行，提升效率。适合AI研发、智能agent工程师做自动化实验、自动调优agent的好帮手。只需写好benchmark任务和program.md，就能让meta-agent自主“熬夜”改进代码，效率爆棚！GitHub: github.com/kevinrgu/autoagent#自动化开发# #智能Agent# #开源项目#

66. 部署AI智能体通常需要复杂的架构，LLM网关负责API路由，数据库管理多租户，安全层防止越权，还要额外的监控工具，来回切换部署颇为麻烦。GoClaw 把AI智能体平台的完整功能全部整合到一起，提供了生产级多租户AI代理解决方案。不仅支持20+ LLM提供商（Anthropic、OpenAI、Groq等）和7大消息渠道（Telegram、Discord、Slack等），还提供5层安全防护、多智能体团队协作、任务看板，甚至内置知识图谱和定时调度。GitHub：github.com/nextlevelbuilder/goclaw主要功能：- 多租户PostgreSQL隔离，每个用户独立工作空间和加密API密钥（AES-256-GCM）；- 20+ LLM提供商原生支持，含提示缓存和扩展思考模式；- 7大消息渠道接入，实时流式对话和多媒体处理；- AI智能体团队协作，支持同步/异步委托、共享任务看板；- 内置工具集：文件操作、网络搜索、浏览器自动化、图像/音频/视频生成；- 5层安全体系+速率限制、提示注入检测、生产级可观测性（OTel）；- 单二进制部署（~25MB），支持Docker Compose一键启动，$5 VPS即可运行。支持 Web仪表盘、Docker多平台部署，通过 make up 一键本地运行，适合AI开发者、团队和企业使用。#AI智能体##Golang# #多智能体# #LLM网关#

67. Hermes Agent：一个能自己变聪明自我进化的AI Agent?

68. 本体+ 大模型：Knora 如何破解企业AI落地中的幻觉与执行断层难题

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

70. 用AI的方式，重新打开飞书！【建议收藏】

71. 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

72. AI 智能体开发常常需要折腾各种框架和工具，LLM 模型调用繁琐，工具集成复杂，状态管理还得自己从头搭，调试起来异常麻烦。AI 智能体实战速成指南把从零到企业级落地的全流程浓缩成一套完整方案，助你快速上手实战。不仅有核心概念详解和架构设计，还提供 LangGraph、CrewAI 等框架实战案例、完整代码仓库，甚至企业级部署指南和优化策略。didilili.github.io/ai-agents-from-zero主要内容：- 核心概念详解，包括智能体架构、工具调用和记忆机制；- 多框架实战教程，支持 LangGraph、CrewAI、AutoGen 等主流方案；- 完整代码示例，从简单聊天机器人到复杂多代理协作；- 企业级落地指南，涵盖 RAG 集成、监控部署和性能优化；- 状态管理和调试工具，简化开发迭代流程；- 实际案例解析，如客服、销售和数据分析智能体。支持在线阅读和本地克隆，多平台浏览器访问，适合开发者、产品经理和企业团队快速上手 AI 智能体。#AI智能体##人工智能#

73. 理想战略调整带来的人员调整，外界看向来残酷。朗咸朋朗博不再接管自动驾驶业务，转而负责硬件体团队。理想从端到端，VLM到VLA，各个技术架构切换带来不一样的人员变革，来到今天可以说是画下句点。这意味着理想自动驾驶不再归类为独立的部门，可以说消失了，并入一整个软件体部门，包括智驾和座舱，他们从整个空间智能的概念讲，是不分家，都在勾晓菲下，勾晓菲之前是理想智能空间副总裁，现在全面接管，统筹整个软件体。当然硬件在整个市场上也有新的挑战，全新的供应链，全新的质量管理和工艺良率的把握，和造一台AI大脑的小车一样，难度同样苛刻，也是新的挑战。从李想进入创始人模式开始，做了新的变化就是切换战略，全面转向 AI 具身智能，也做了新的人员调整，至此：理想将研发重组为三大团队：基座模型团队、软件本体团队、硬件本体团队。他们负责人分别为：詹锟、勾晓菲、朗咸朋。#理想汽车#

74. 理解 LangChain 智能体：create_react_agent 与 create_tool_calling_agent

75. 模型只是引擎，Harness才是关键：解析编程智能体的运作逻辑

76. 2月13日，蚂蚁集团开源发布全球首个基于混合线性架构的万亿参数思考模型 Ring-2.5-1T，在长文本生成、数学推理与智能体任务执行上达到开源领先水平，为智能体（Agent）时代的复杂任务处理提供高性能基础支撑。在生成效率上，Ring-2.5-1T在32K以上长文本生成场景中，对比上代模型访存规模降低10倍以上，生成吞吐提升3倍以上。在深度思考能力方面，该模型在国际数学奥林匹克竞赛（IMO 2025）和中国数学奥林匹克（CMO 2025）自测均达到金牌水平（IMO 35分、CMO 105分）。同时，可轻松适配Claude Code等智能体框架与OpenClaw个人AI助理，支持多步规划与工具调用。发布了头条文章：《蚂蚁集团开源Ring-2.5-1T 全球首个混合线性架构万亿参数思考模型来了》 #蚂蚁集团 sh688688[股票]# #ai大模型# #openclaw# 蚂蚁集团开源Ring-2.5-1T 全球首个混合线性架构万亿参数思考模型来了

77. HiClaw 加入 AgentScope，携手 CoPaw 共建多 Agent 的基础设施

78. 鹏说：AI Trading Agent时代下的思考

79. 从“龙虾”狂欢到工厂重构：创新奇智如何用“本体智能体”破解工业AI落地之困？| 甲子光年

80. 看完 Manus、Cursor 分享后的最大收获：避免 Context 的过度工程化才是关键

81. 这篇Vibe Coding文章值得一读！ 1. 深入探讨了 Claude Code 2.0 的进阶使用技巧及其作为 AI 编程智能体的演进过程。 2. 通过对比 Anthropic 与 OpenAI 旗下工具的性能，分析了 Opus 4.5 模型在速度、沟通力及意图检测方面的显著优势。 3. 详细解析了子智能体 (Sub-agents)、上下文工程 (Context Engineering) 及 MCP 服务器等核心机制，揭示了系统如何通过任务拆分和提示词注入来优化处理能力。 4. 分享其个人工作流和自定义指令，提供了从技术小白向高效人机协作转型的实操指南。访问：sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/ #ai创造营# #程序员#

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

83. OpenClaw 源码架构深度解析

84. #IT那些事儿# 比可汗学院和慕课还可汗：AI 同学吵起来了，这才是真正的多 Agent 课堂！清华研究团队开源的这个 OpenMAIC，让我惊了，感觉比可汗学院和慕课还可汗。你发一句话（图一）或一个文件，几分钟内就自动生成一堂完整的 AI 多 Agent 互动课堂——AI 老师语音讲解 + 白板实时画重点（图二），AI 同学和研究生助理跟你有问有答引导热烈讨论，有的“同学”思辨能力强，有的“同学”靠直觉（图三），实时测验、项目式学习（PBL）全都有，包教包会，还能用麦克风直接对话。OpenMAIC 和小龙虾一样，也是“模型无关（model-agnostic）”架构，如果在本地搭建推荐配置高性价比推理模型（如 Gemini Flash），不过对于不同角色可以用不同模型（老师 / 学生 / 助教），这样能省点钱。OpenMAIC 技术本质上是：RAG + 多Agent系统 + 教学流程建模 + 多模态交互。它的核心创新是多Agent编排。每个 Agent 都是一个 LLM prompt + memory，通过 graph 控制调用顺序，支持循环（讨论 → 修正 → 再讲），这就是为什么能看到“AI同学吵起来”（图四）。我看很多人第一反应就是那 AI 幻觉怎么办？是啊，如何从工程上解决课堂多 AI Agent 的一致性和收敛性问题呢？首先，在多 Agent 课堂里，幻觉不是 bug，而是系统性风险！因为这个课堂里有多角色（老师 / 学生 / 助教）、长上下文（整堂课）、开放问题（学生提问），这比单轮问答难一个数量级，一旦一个 Agent 说错，其他 Agent 接着“合理化”，就会形成共识，强化错误。其次，我在研究过的 SWE-CI 问题中就曾说过“上下文漂移 + 约束遗忘”（参见：网页链接），那么在多 Agent 课堂里就会表现为越讲越偏和讨论跑题。那么，如何解决呢？猜测大概要分六层防护。第一层，RAG Grounding（检索增强生成“锚定”在可验证的外部真实数据源上）第二层，角色降权（主要是 AI “学生”）第三层，提高AI“助理”的校验机制，或者单独增加一个裁决 Agent第四层，结构化输出（防止漂移）第五层，建立课堂“收敛机制”第六层，全局一致性监控总结一下，要想抑制多 Agent 课堂的幻觉，必须要求（比如以 SKILLS 的方式）：1）所有知识必须引用来源2）每一模块必须包含“总结 + 测验”3）学生 Agent 不能给结论4）加入 Verifier Agent 做一致性检查OpenMAIC 的出现，标志着 AI 教育从“单点问答”迈向“系统性课堂编排”的质变。它的真正价值，不在于“让 AI 会讲课”，而在于它首次把教育问题转化为一个可工程化的多 Agent 系统一致性与收敛性问题——有争论、有纠错、有收敛。但这也意味着，任何想在教育场景中认真落地多 Agent 系统的团队，都必须把"幻觉治理"当作头等大事来设计。上文提到的六层防护体系，本质上是在回答同一个问题：如何让一群 AI 在开放主题编排和开放对话中，仍然对真理负责？这不只是 OpenMAIC 的工程挑战，也是整个 Agentic AI 时代的核心命题。教育场景，恰好是压力测试它的最好战场——因为学生不会假装听懂，错了就是错了。

85. #IT那些事儿# 烟花老师做了 fireworks-tech-graph，一个专门生成技术图的 Claude Code Skill。「画一张 Multi-Agent 协作图：Orchestrator 调度 3 个 SubAgent，分别负责搜索、计算和代码执行，最后汇聚到 Aggregator 输出结果，玻璃态风格」然后它会： ① 识别图类型 → Agent 架构图 ② 分配语义形状 → Orchestrator 用六边形，Agent 用六边形，存储用圆柱体 ③ 用语义颜色编码箭头 → 蓝色主流程、橙色控制流、绿色读写 ④ 自动导出 SVG + 1920px PNG 整个过程不需要写 DSL，不需要打开任何工具，一句话描述，图就出来了。目前支持 8 种图类型、5 种视觉风格，AI/Agent 领域的常见 Pattern 全部内置（RAG、Mem0、Agentic Search、Multi-Agent、Tool Call 等）。仓库地址：github.com/yizhiyanhua-ai/fireworks-tech-graph

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

87. Gemini CLI 在处理非编程任务的时候，比 Claude Code 有很多优势。它对自然语言的理解更好，它直接接入 Google Search，它每天有 1000 次免费请求和大量的免费 token，它有 Google 账户就能用，它甚至在 sub-agent 调度上有很多聪明的做法。最近常用，推荐各位试试。（写代码也不错，当然不如 Claude 确实。）

88. Aloudata Agent 智能数据分析新范式:从"黑盒对话"到"白盒协作"

89. 构建开放智能体生态：AgentScope 如何用 A2A 协议与 Nacos 打通协作壁垒？

90. 刚开始接触 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##科技先锋官#

91. AI时代，会有一套全新的软件工程规范的，你爸以前学的软件工程方法，都过时了。但加加，记得关注Harness Engineering，我认为比Vibe Coding，是更正确的工程观念。你看，先接触市场上流行的Vibe Code，如果迷信就容易错失后面的Harness Engineering。但，Just do it，先用Vibe Coding写两个项目，知道优缺点，就容易接受更好的新概念。 // Vibe Coding 之后最主流、最受关注的两个新兴工程概念是：Agentic Engineering（智能体工程）和 Harness Engineering（驾驭工程）。它们是 AI 编程从 “随性生成” 到 “工程化可控” 的关键演进。 #父女日常#

92. 掌握AI Agent开发：开发者锁定未来五年价值的硬核竞争力

93. 《扣子开发 AI Agent 智能体应用》011-扣子工作流详解（工作流逻辑结构和常见节点）

94. 构建自主AI：深入A2A协议的智能体开发——让智能体真正“互联”起来

95. OpenClaw 多工作区与多 Agent 配置实战指南：从踩坑到精通

96. 【Craft Agents：把 AI 协作从命令行拉回直观应用层】快速阅读：Craft Agents 试图把 AI 协作从冷冰冰的命令行环境拉回到直观的应用层。它通过文档化的工作流和零配置集成，让 Agent 的能力更像是一个可管理的收件箱。---以前用 Agent 像是在裸写汇编，满屏的 CLI 和配置文件带来的上下文切换极其痛苦。Craft Agents 跳过了代码编辑器，直接给出了一个类似邮件收件箱的工作流。你可以直接对它说：“把 Slack 和 GitHub 接进来”。它会自己去读文档、处理凭证。这很像操作系统自动挂载远程文件系统。甚至连没有 API 的网站，它也能通过内置的 Chromium 浏览器去模拟点击和抓取数据。这种设计里有一个很有意思的模式：Explore vs Execute。先让 Agent 在只读状态下规划，确认无误后再授权执行。这种权限控制把 AI 从一个黑盒变成了一个可观测的任务流。你可以像管理文档一样管理会话，支持多任务后台运行。有网友提到，这种“文档式”的交互让非开发者也能接管复杂的自动化流程。现在的 Agent 还是太像一个对话框了。如果有一天，所有的软件 API 都能像插件一样被自动发现并挂载，我们还需要所谓的“应用”吗？agents.craft.do

97. 回复@磨牙吮血cc:试试 Ralph Wiggum Plugin github.com/anthropics/claude-code/blob/main/plugins/ralph-wiggum/README.md //@磨牙吮血cc:宝玉老师你好，我现在还是只会让code agent一个任务一个任务的完成，怎么让它长时间运行或者开多个sub agent 运行呢？不考虑token限制。谢谢🙏

98. 3月18日，智己汽车举办发布会，推出行业首个超级智能体IM Ultra Agent，全球首次将千问大模型量产上车，成为首个落地千问车载大模型的车企。该智能体基于IM Fusion Nova舱驾一体三域融合架构，打通线控底盘、智驾与座舱，实现“听懂意图、自主规划、一键执行”，支持模糊指令与情感交互，联动阿里生态完成导航、支付、生活服务等全场景代劳。同时发布IM AD Zeta智驾系统，以L4级能力赋能高阶辅助驾驶。发布会官宣智己LS8于3月26日开启预售，定位30万内8系旗舰SUV，搭载千问大模型、全线控灵蜥底盘与四轮转向，主打“专属AI司机助理”，推动智能出行进入具身智能新阶段。

99. 小鹏自动驾驶、智能座舱中心合并，新成立通用智能中心⭐组织架构核心调整- 原架构：智能座舱中心与自动驾驶中心为两大独立一级部门，负责人均直接向何小鹏汇报；- 调整后：两大部门合并，集中 AI 资源形成统一中台，解决此前开发节奏、OTA 更新割裂问题，确立“ AI +软件”核心团队体系；⭐核心战略方向- 技术与定位：推动座舱与智驾技术合流打造“超级智能体”，深耕物理 AI 领域，目标升级为全球物理 AI 科技公司；- 产品落地：1 月发布 4 款新车，顶配搭载三颗图灵芯片，智驾第二代 VLA 大模型计划 3 月推送；信源：晚点Auto#新能源汽车##小鹏汽车#

100. 智己LS8将于3月26日正式开启预售，这次LS8在Fusion Nova舱驾一体的全新架构下首发搭载千问大模型，IM Ultra Agent 智己超级智能体让每一个智己用户都拥有属于自己的专属司机助理。智能架构 IM Fusion Nova重新定义了智能汽车的架构标准：第一层，实现全域融合的物理基座全线控底盘第二层，行为控制的基座智驾大模型第三层，全域智慧千问大模型从底层架构上，通过异构计算，完成整体统一行动AI 能听懂读懂你的需求，还能精准掌控车辆的动作#千问大模型首发搭载智己LS8##智己LS8预售发布定档3月26日#

101. 金融可信智能体的工程范式——从单Agent到自进化，蚂蚁数科如何解决归因难题？

102. 任务分解与协作

103. AI Agent 进阶

104. Sub-Agents 和 Agent Teams 有啥区别？一文讲清多智能体协作的两种范式

105. Subagent 崛起

106. 终于弄清楚什么是子智能体Sub-Agents？什么是智能体团队Agent Teams了！

107. [Alan の手札] OpenClaw-该用Multi-Agent还是主Agent+Sub-Agent

108. SubAgent技术深度解析

109. Subagents vs. Agent Teams

110. AI智能体架构选择

111. 子智能体 vs 智能体团队

112. Langchain ｜如何选择合适的多智能体架构

113. OpenClaw vs Hermes Agent

114. 龙虾（OpenClaw） Agent 模式怎么选"多 Agent"与"Sub-Agent"的差别

115. AI Agent 三种设计范式

116. 第2篇

117. 通用智能体为何无法“通用”？智能体编排架构在企业中的关键作用

118. 多Agent协作是使用Subagents还是使用Agent Teams？

119. 多Agent协作实战

120. 介绍一下多 Agent 如何实现工作？多个 Agent 之间如何协调和分工？

121. Agent学习笔记（八）多智能体系统-1

122. AI Agent 架构设计（四）

123. 字节三面

124. Harness Engineering

125. Agent 开发实战

126. AI Agent 核心概念详解

127. 如何多个 AI Agent 跨任务自主协作

128. OpenClaw Agent 机制深度解析

129. 同步阻塞 vs 异步编排

130. LangGraph（七）快速入门｜多 Agent 协作

131. 多Agent协作

132. AI Agent学习 | Multi-Agent协作

133. Agent Teams

134. 多个Agent如何协作

135. 17种Agent架构演进图鉴

136. AI Agent 智能体 - Multi-Agent 架构入门

137. Skills、MCP、Sub-Agent 到底差在哪？AI Agent 体系概念辨析

138. Spring Boot接入MCP+多Sub Agent协作+OpenCode一键搞定

139. Agentic Engineering ⑫

140. 2026 AI Agent 框架选型

141. Agent架构演进与科学选型指南

142. 智能体｜Agent 架构演进与选型

143. AI Agent 工程化

144. 从Prompt到Harness

145. Agent Harness

146. 【驾驭智能体 02】从数学角度看智能体局限，以及我们该如何工程化实现 | Andrej Karpathy

147. 程序员必读！收藏这份AI智能体落地指南

148. 大模型应用

149. 品牌升级 | 金融智能体AXEINSIGHT

150. 大模型、智能体与MCP服务的关系详解

151. 多 Agent 协作：AI 团队的崛起

152. Hiclaw：开源 Agent 团队协作系统，让多个 AI Agent 在 Matrix 中协作

153. 角色分工 × 群聊协商，打造透明可干预的多agent协作框架

154. Microsoft AutoGen 框架总结

155. AutoGen 架构演进全梳理：从 v0.4 到 Microsoft Agent Framework

156. LangChain 1.0 VS LangGraph 1.0：智能体我该用哪一个？

157. 一篇文章介绍当前主流的多 Agent 架构

158. 吴恩达agent-skills课程笔记总结3：Skills vs Tools, MCP, and Subagents

159. MCP与Skills深度解析：构建高效SubAgent架构

160. OpenClaw探秘（三）Agent 的心脏——三层嵌套引擎与思考-行动-复盘闭环

161. 【AI编程】智能Agent团队必备的三层记忆架构

162. Deep Agents框架，多智能体搭建的下一代AI架构

163. ClawMem Agent 团队协作实战: 用共享记忆让Agent“稳稳接住”你的工作流

164. 什么是 AutoGen？

165. OpenClaw 的 AI 操作系统是如何炼成的？拆解 Channels、Agents、Tools 三层架构

166. 告别单打独斗！Claude Code Sub Agents如何组建你的AI专家军团

167. Agent Teams 实战：从单兵作战到 AI 团队协作

168. Agent组队干活了！多Agent协作平台让AI变成真正的团队

169. 别再只会调接口了，用 AutoGen 玩真的多智能体

170. The Rise of Subagents: SubAgent工作原理剖析

171. 多 Agent 协作：让 AI 团队完成复杂项目

172. 一人顶一个开发连！Claude Code 多智能体 Sub-agent 深度实战指南还在让 AI 一个人扛下所有代码？别再折磨它的上下文了！本期视频带你手把手解锁 Claude Code 的“分身术”——Sub-agents。从如何用斜杠 agents 命令创建专属专家，到开启隐藏的并行协作模式，教你打造一支 24 小时待命的虚拟开发团队。内含 YAML 配置干货，建议收藏吃灰（划掉）反复观看！🚀 #ClaudeCode #AI编程 #Subagents #多智能体 #程序员

173. Claude Code源码泄漏！扒透第一梯队AI Agent的工程架构真相

174. 深入解析Claude Code的Subagent机制

175. 多 Agent 协作框架 Routa：让 AI 团队真正落地

176. 一个人能管几个 AI？基于OpenClaw多 Agent 协作实践

177. AutoGen：多智能体协作，AI应用新范式

178. 「智能体开发入门」LangChain 支持的哪些 Agent 编排模式？

179. 如何通过 Skills、MCP 和 Subagents 构建 AI Agent 能力操作系统？

180. [Anthropic-25.6.13] How we built our multi-agent research system

181. LangGraph智能体开发设计模式（四）——LangGraph多智能体设计模式：网络架构

182. 多Agent协作效率提升300%：团队实践经验分享

183. Agent Team 协作的 6 种范式｜架构选型指南

184. OpenClaw多Agent协作：让AI团队分工合作

185. 智能体开发用什么

186. AutoGen 多Agent代码技术总结

187. AI 团队协作的里程碑：多角色 Agent 共同研发

188. Agent架构深度解析：从技术原理到未来生态的六层框架

189. 手撕Claude Sub Agent：从创建、工作流到销毁，全生命周期实战、Claude高级教程、手写一个Sub Agent，彻底搞懂AI Agent内核

190. openclaw上下文溢出，多agent协作。多agent团队协作，主main分配任务给子agent，一人指挥一个团队。分工协作，效率翻倍的同时，还能防止上下文溢出。不占主main聊天窗口，子agent后台工作，你和主main飞书聊天做其他任务。#多agent系统 #多agent #openclaw #memory记忆 #上下文保存

191. 多Agent协作（Multi-Agent Systems）

192. AI智能体技术架构深度解析：8层架构揭秘，助力企业落地与应用！

193. OpenClaw 后台长期运行关键：Sub Agent + TMUX

194. Langchain深度智能体框架DeepAgent解析

195. 9.Agent 团队协作

196. Agent-template这个 AI Agent 模板凭什么刷爆 GitHub？

197. 构建多智能体 AI 应用的5个最佳框架所谓多智能体系统（Multi-Agent System, MAS），这些智能体能够感知环境、与其他智能体交互，并通过协作解决复杂的任务。这几天完整整理了多agent系统架构设计模式及协作模式 ✅主要整理的agent设计为： 🅰️多agent开发框架 MetaGPT，AutoGen，CrewAI，Langgraph 🅱️多agent协作方式 MetaGPT，AutoGen，XAgent，含内循环，外循环，planagent，toolagent 💾可以归纳出一个等式：多智能体=智能体 + 环境 + SOP + 评审 + 通信 + 成本#大模型 #大语言模型 #大模型微调 #大模型入门 #大模型应用

198. Agent架构选型：好架构都是逼出来的 Agent架构选型：好架构都是逼出来的|claude《Building Effective AI Agents：Architecture Patterns and Implementation Frameworks》④ 文章发布于2026/3/5，链接https://claude.com/blog/common-workflow-patterns-for-ai-agents-and-when-to-use-them 报告下载链接：https://resources.anthropic.com/ty-building-effective-ai-agents 评论区说的2024年的是另外一篇。 #大模型开发 #ai应用开发 #agent #多agent #agent

199. AI产品一图流：AI Agent技术架构怎么做？

200. OpenClaw理念落地：国内团队侠客工坊探索多智能体协同控制架构

Sub-Agents架构上下文丢失率反超Agent Teams 37%，任务协作模式选错才是AI系统失效的根源

精选参考来源