当前位置：

社区首页

电脑数码

软件应用

服务软件

AIGC文章详情

多Agent不是炫技，而是重构开发流程

源自172位全网作者

05-28 13:13

精选参考来源

看到很多朋友问过一个问题，为什么给我的 Claude Code 安排任务，它都不会一口气执行完，而是跑最多几十分钟就停下来，然后问我要不要继续。例如让它把项目中的单测全部补全（大概 1k 个），它跑了大概 200 个就停下来了。cc 并不是对一句话任务抗拒，如果不理解它的执行机制，很难设计出能跑长程任务的 harness 流程。在执行一个超大任务的时候，单 agent 的执行流程大概是这样的：1）刚开始是高效模式，指令遵循效果特别棒；2）跑了大概 80k tokens 的时候，context 开始逼近 compact 阈值；3）紧接着，对话历史被压缩为摘要，模型开始忘记刚才修复单测的细节；4）再经过一两轮 auto-compact，它甚至会开始重复检查已修复的测试，当触发 maxTurns 并且 response 没有 ToolUse 指令时，模型会退出任务，然后开始询问用户："我已经修复了约 200 个测试，要继续吗？"如果你在当前 session，回复继续，接下来的工作，它会做的更加不符合预期，并且退出得更快。任何试图在一个 agent session 内完成海量工作的方案，最终都会碰到 context 膨胀 → compact → 信息丢失 → 效率下降的问题。其实优化方向也特别简单，设计一个主-子 Agent 的运行模式（任务调度器），同时将任务进度写到 file system 中（进度持久化），每个子 agent 有独立 context、独立退出逻辑，主 agent 只负责调度和进度追踪，从而绕过单一 agent 的所有瓶颈。因此给 cc 的指令需要包含至少这三部分：1）任务分解。不要给一个无边界的指令（如修复所有单测），而是先扫描出所有失败测试，按目录或模块分组，每组 15-30 个，作为一个独立子任务。关键是每个子任务的 prompt 必须自包含——写清楚文件路径、错误现象、期望行为，不能写"根据之前的分析来修复"，因为子 agent 看不到父 agent 的历史。2）进度持久化。在项目根目录维护一个 progress.json，记录 completed / failed / pending 三个列表。主 agent 每轮调度前读这个文件决定下一批任务，子 agent 完成后更新对应条目。这样即使主 agent 自己被 compact，重读文件就能恢复全部状态。3）失败策略。子 agent 报错时，如果错误可修复，用 SendMessage 继续同一个子 agent（保留错误上下文更高效）；如果方向完全错了，启动新的子 agent 避免锚定在错误路径上；多次失败则上报用户，不要无限重试烧 token。Claude Code 其实已经内建了这套能力。最直接的方式是启用 Coordinator Mode（输入 /coordinator），主 agent 自动变成纯调度者：它不执行任何实际工具调用，只负责理解子 agent 的返回结果、合成下一步的具体指令、并行派发独立任务；而每个子 agent 会通过 AgentTool 启动，它们有独立 context。记住一句话就行了：设计多个 agents，各司其职、快进快出，把进度交给文件系统来记忆。

吴恩达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

全部
来源

内容由AI生成

1. 看到很多朋友问过一个问题，为什么给我的 Claude Code 安排任务，它都不会一口气执行完，而是跑最多几十分钟就停下来，然后问我要不要继续。例如让它把项目中的单测全部补全（大概 1k 个），它跑了大概 200 个就停下来了。cc 并不是对一句话任务抗拒，如果不理解它的执行机制，很难设计出能跑长程任务的 harness 流程。在执行一个超大任务的时候，单 agent 的执行流程大概是这样的：1）刚开始是高效模式，指令遵循效果特别棒；2）跑了大概 80k tokens 的时候，context 开始逼近 compact 阈值；3）紧接着，对话历史被压缩为摘要，模型开始忘记刚才修复单测的细节；4）再经过一两轮 auto-compact，它甚至会开始重复检查已修复的测试，当触发 maxTurns 并且 response 没有 ToolUse 指令时，模型会退出任务，然后开始询问用户："我已经修复了约 200 个测试，要继续吗？"如果你在当前 session，回复继续，接下来的工作，它会做的更加不符合预期，并且退出得更快。任何试图在一个 agent session 内完成海量工作的方案，最终都会碰到 context 膨胀 → compact → 信息丢失 → 效率下降的问题。其实优化方向也特别简单，设计一个主-子 Agent 的运行模式（任务调度器），同时将任务进度写到 file system 中（进度持久化），每个子 agent 有独立 context、独立退出逻辑，主 agent 只负责调度和进度追踪，从而绕过单一 agent 的所有瓶颈。因此给 cc 的指令需要包含至少这三部分：1）任务分解。不要给一个无边界的指令（如修复所有单测），而是先扫描出所有失败测试，按目录或模块分组，每组 15-30 个，作为一个独立子任务。关键是每个子任务的 prompt 必须自包含——写清楚文件路径、错误现象、期望行为，不能写"根据之前的分析来修复"，因为子 agent 看不到父 agent 的历史。2）进度持久化。在项目根目录维护一个 progress.json，记录 completed / failed / pending 三个列表。主 agent 每轮调度前读这个文件决定下一批任务，子 agent 完成后更新对应条目。这样即使主 agent 自己被 compact，重读文件就能恢复全部状态。3）失败策略。子 agent 报错时，如果错误可修复，用 SendMessage 继续同一个子 agent（保留错误上下文更高效）；如果方向完全错了，启动新的子 agent 避免锚定在错误路径上；多次失败则上报用户，不要无限重试烧 token。Claude Code 其实已经内建了这套能力。最直接的方式是启用 Coordinator Mode（输入 /coordinator），主 agent 自动变成纯调度者：它不执行任何实际工具调用，只负责理解子 agent 的返回结果、合成下一步的具体指令、并行派发独立任务；而每个子 agent 会通过 AgentTool 启动，它们有独立 context。记住一句话就行了：设计多个 agents，各司其职、快进快出，把进度交给文件系统来记忆。

2. 吴恩达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

3. 用DAA衡量智能体百度智能云用“新全栈”重新定义AI云｜甲子光年

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

5. Context 还不够，Harness 才是 Agent 工程优化的正解？

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

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

8. 删掉 OpenClaw！Hermes Agent 才是真王炸，一键本地部署 +模型接入全教程（避坑指南） | 零度解说

9. Harness项目推荐丨CLI-Anything 、CrewAI、LangGraph、EigenFlux....

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

11. Claude Code或智能体给每个工具调用设明确的失败路径，很重要！「让 agent 自己决定怎么重试」是生产环境最危险的设计。如果你一个小功能执行了很长时间，浪费了很多token，大概率就是在无效重试了。这本质上是因为没有给失败定义出口。1. 重试循环是最隐蔽的死亡模式最常见的 agent 特有失败模式：工具调用报错 → agent 原样重试 → 还是报错 → 再重试。整个过程 agent 不说话，任务返回看起来像在跑，实际上它在用完全相同的参数一遍遍重复同一个失败的调用。通常要等到账单来了才会发现，或者几小时后下游任务给出错误结果时才察觉——而这时候已经连续失败了几十次了。2. 四个必须在架构层定义的机制1）每个 tool call 必须有重试上限 + fallback 行为，而不是开放式循环。重试 3 次还没成功，就触发 fallback（降级处理、跳过、或转为人工审批），而不是继续重试。2）熔断器（Circuit Breaker）：连续 N 次违规（报错/超时/超 token）后，自动停止所有 LLM 调用，等人工来 reset。这是防止花费大量token 的最后一道防线。开源库 agent-cost-guardrails 就是做这个的，纯 Python，零基础设施，可以直接挂进 CrewAI / AutoGen / LangGraph。3）Human-in-the-loop 关卡要提前定义，不能让 agent 自己判断「这件事要不要问人」。正确做法是：列出哪些操作类型必须经过人工确认（比如写入生产数据库、发送外部通知、超过一定金额的操作），在架构里硬编码这些关卡。4）每个 agent 的决策要可追溯：哪个 agent、调用了哪个工具、传了什么参数、返回了什么、为什么做这个决定——完整的 trace。如果你做不到这一点，生产环境 debug 就是考古——找到一堆 error log，但不知道哪个是根因。3. 核心设计原则1）不要让 agent 决定如何从自己的错误中恢复。这是一个没有出口的控制循环。2）重试、路由、失败恢复——这些逻辑必须在 agent 上层的 orchestration 层实现，不能依赖 agent 自己判断。agent 只负责执行，异常处理交给架构层管。#HOW I AI# #程序员#

12. Claude Code 的核心是一个 while 循环：模型生成响应 → 如果包含工具调用，执行 → 结果返回 → 模型生成下一个响应 → 持续循环。就这么一个循环，被工程化成一个完整的产品，写了将近 30 多万行代码。从整体代码设计来看，可以认为，Claude Code = 模型 + Harness，而 Harness = 工具系统 × 上下文工程 × 自主循环。其中，工具系统和上下文工程做了大量的设计。CC 的工具系统有着自己的标准化设计，它会明确约束模型不要执行 find、grep、cat、head 通用操作，而是走 GrepTool、GlobTool 等专用工具，因为这些内建工具会输出可审计、结构化的日志，让操作更加透明可控。同时，工具本身也带有权限级别和验证逻辑。例如 Edit 工具为了避免交叉覆盖，会要求先 Read；Git 工具对 push force 类高风险操作会做 prompt 约束和 UI 警告。类似的设计很多，目的是在工具层建立清晰的边界和反馈机制，让模型在调用时有约束、有校验，减少越界操作和错误扩散。而在上下文管理上，CC 的管控也无所不用其极。它通过多种压缩策略和动态机制，确保模型在任何时刻只接触当前任务最相关的信息。压缩策略的核心机制包括 MicroCompact、AutoCompact，以及不同触发条件下的会话压缩、记忆替换和裁剪策略。在文件加载机制上，针对工具定义与能力暴露，也设计了 Just-In-Time 策略，文件不预加载，只保留路径，需要时再通过工具读取。此外，还有 Sub-Agent 的设计，它通过上下文隔离的方式，让不同子任务的相关信息互不干扰，进一步降低了主循环的认知负载，确保主循环逻辑干净且稳定。Claude Code 不仅是在工具系统和上下文管理上做文章，模型为了 Harness 效果更好，也开始配合对 Agentic 行为做专项优化。例如 Opus 4.7 在指令遵循上就明确提到 "Opus 4.7 takes the instructions literally"，这对 Agent 来说非常关键。Agent 的行为边界往往写在 system prompt 里，模型层做了增强学习后，模型在指令遵守方面会表现更出色，这对 Agent 的稳定性和可靠性会有极大提升。OpenClaw/Hermes Agent/Claude Code 产生了大量 Agent 调用数据，这些数据也会继续反哺模型能力的迭代。从当前发展趋势可以推断，未来模型的进化，一定也会逐步内化工具调用策略、上下文压缩策略，甚至学会自我约束行为边界。那么，今天 CC 里写的这些 Harness 逻辑，注定也会被模型吃掉。也就是说，Harness 也是一个过渡性的产物。🐶

13. 多Agent一定比单Agent更强吗？AI应用到底该在什么节点拆分？

14. Agent 构建变轻、Agent 架构变薄，什么正在变厚？

15. 《扣子开发 AI Agent 智能体应用》001-智能体概述

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

17. 专访北电数智谢东：从单点到系统，星火・AI云 2.0如何重构AI时代生产力体系｜甲子光年

18. 【拆解 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

19. 与其追求成为一个从不犯错的人，不如打造一个就算犯错也能被纠正的流程。#大咖观察 #红衣聊AI #人工智能 #大模型

20. 【保姆级】OpenClaw 全网最细教学：安装→Skills实战→多Agent协作，1 小时全精通！

21. 像对待开发者一样对待你的编码代理网页链接这篇文章认为，要像管理初级开发者一样管理编码agent。单个 agent 在一个目录里工作还勉强可行，但多个 agent 并行写代码时，很快会因为 Git 分支、文件系统缓存、Docker Compose 容器、端口和数据库等共享资源互相干扰。解决办法是给每个 agent 一套独立的开发者环境：自己的项目副本、运行时、Compose 命名空间、本地 URL 和独立分支。这样 agent 的工作流就更接近真人开发者：各自开发、提交分支、接受 review、能随时丢弃实验环境。提升 agent 生产力的关键不只是模型能力，而是给它们配套人类团队早已习惯的工程协作基础设施。#AI创造营#

22. 在线开发智能代理应用，经常需要协调模型推理、工具调用、消息管理、记忆存储等多项功能，流程复杂难以掌控。AgentScope 专为构建“可见、可理解、可信赖”的智能代理而打造，提供了从模型调用到工具集成、从多代理协作到强化学习微调的全套开发框架。它内置了 ReAct 代理、多代理消息中心、实时语音交互、人机协同调控、持久化记忆与规划组件，支持快速搭建和生产部署，兼容本地、云端和 Kubernetes 环境。GitHub：github.com/agentscope-ai/agentscope主要功能：- 易用的 ReAct Agent，拥有模型推理与多工具调用能力；- 丰富的工具生态，可扩展集成各类 API 和本地命令执行；- 内建多代理消息中心，支持同行协作和复杂工作流管理；- 支持实时语音输入输出，打造声音交互的智能助手；- 强化学习和模型微调支持，提升代理能力和任务表现；- 人机协同机制，允许实时中断与调整代理行为；- 灵活记忆模块，支持数据库持久化与记忆压缩。只需 Python 3.10 以上环境，pip 一键安装即可快速上手，适合 AI开发者、研究者及企业团队打造智能多代理应用。#AI开发# #智能代理# #多代理协作#

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

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

25. 当你的 Agent 会“多轮思考”，Trace 却还停留在单轮：阿里云 CMS OpenClaw 可观测插件升级

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

27. 全球首家无人公司来了！一整个AI团队替人上班，不吃饭不摸鱼，普通人的数字员工时代真的来了吗？#大咖观察 #红衣聊AI #智能体 #AI时代

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

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

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

31. 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创造营# #科技#

32. 在智能体开发中，经常面临模型智能与多样工具、记忆和安全治理的整合难题。OpenHarness 是一个轻量级的开源 Agent Harness 框架，专为研究者和开发者设计，提供了完整的智能体基础设施。它不仅支持丰富的 43 种工具（文件、Shell、搜索、Web、任务管理等），还能动态加载 40+ 技能，支持插件生态扩展，还拥有细粒度多级权限治理和多智能体协作能力。核心特点包括：- 持续的 Agent 循环（流式工具调用，API 重试，代币计数等）- 丰富的工具和技能支持，结合 Anthropic 生态兼容性强- 持久化记忆、上下文压缩与会话续接- 多重权限管理，交互式审批保障安全- 多代理团队协作和任务委派- React 终端 UI，提供交互式命令选择和权限弹窗支持 Python 3.10+，提供一键命令行启动（`oh`），适合构建定制化智能体及多任务协作系统。GitHub：github.com/HKUDS/OpenHarness主要功能：- 43 种工具：文件操作、Shell 命令、网络搜索、任务管理等- 40+ 按需加载技能，涵盖代码提交、测试、安全审查等- 灵活插件系统，方便自定义命令、事件钩子和多智能体- 多级权限配置，确保执行安全- 多智能体协调，支持子智能体创建和团队管理- 交互式 React 终端UI，提升用户体验如果你想了解国产版 Claude 轻量实现，或是打造高效可扩展的智能体框架，OpenHarness 绝对值得一试！#开源智能体# #AgentHarness# #AI开发#

33. AI智能体调度师是2026年随着多智能体系统普及而兴起的新兴职业，其核心工作是将多个专业AI智能体组建为一个高效、可控的“数字智能团队”，担任总指挥官和流程架构师，通过精准的任务拆解、动态调度编排、工具集成管理以及全链路监控治理，让多Agent系统稳定完成复杂业务目标。具体来说，首先将模糊业务需求转化为结构化的任务树，明确依赖关系、优先级、终止条件和回滚机制；其次是最核心的智能体调度环节，动态决定任务路由、并行策略、冲突仲裁、重试降级及角色切换；接着严格管理工具调用、API对接和外部系统集成，确保安全合规与审计；最后通过实时观测系统监控性能、成本与风险，并基于数据持续迭代优化调度策略。典型工作场景包括企业智能客服全流程自动化、营销报告自动生成以及跨系统业务闭环等。该岗位与提示词工程师相比更强调系统级运营与动态协调，需要从业者具备结构化思维、多智能体框架熟练度和业务理解力，目前多以AI应用架构师或多智能体开发工程师名义招聘，已成为企业智能体化转型的关键角色之一，前景广阔。#新媒沈阳聊ai#

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

35. 攻克幻觉与协同：同程旅行DataAgent如何构建企业级智能分析营销平台

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

37. 企业专属 Agent 开发实践

38. 让多智能体系统真正「指哪打哪」！中科院新作CVPC：系统定义VLM跨视角点级对应能力！

39. 我只是做了杯咖啡，群里的7个AI竟然已经自己互相 @ 走完流程了！不用再给人机当人肉搬运工，谁懂啊，我听到了AI干活的关键一环，“啪嗒”一声彻底扣上了 #ai #飞书 #飞书CLI #AI干活 #AI员工

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

41. 今天 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##科技先锋官#

42. Harness Engineering 在讨论什么：三个 Scaling 维度的统一框架网页链接2026 年第一季度，OpenAI、Cursor 和 Anthropic 先后发布了各自在 agent-first 软件开发上的实践报告。三篇文章都被归入同一个术语：harness engineering。但仔细读下来，它们讲的几乎是三件完全不同的事。OpenAI 的 harness engineering 讲的是环境设计：文档体系、架构约束、可观测性基础设施，让 agent 在一个被精心设计过的工作环境里可靠地生产代码。Cursor 的 self-driving codebases 和 scaling agents 讲的是协调架构：几百个 agent 同时工作，怎么分工、怎么并行、怎么收敛。Anthropic 的 harness design for long-running apps 讲的是运行时纠偏：一个 agent 连续跑几个小时，怎么在过程中保持方向和质量。这三篇文章的读者群高度重叠，用的术语高度一致，但各自回答的工程问题截然不同。这正是 harness engineering 这个词在当前讨论中造成混乱的根源：人们用同一个词在讨论不同层面的问题，而大量二手解读甚至还停留在两年前的 multi-agent 虚拟团队概念里，离这三篇文章的实际内容更远。这篇文章尝试提供一个统一框架来理清这些讨论。核心论点是：harness engineering 的本质是让 AI 构建软件变得 scalable，而 scalability 有三个独立的维度。三家各自解了其中一个。

43. AI Agent 的“进化之路”：从研究原型到生产级记忆系统，技术趋势与产品对比

44. AAAI 2026 Oral！华科最新提出GRANT：首次融合运筹学与3D空间感知，解锁具身智能并行任务执行新范式

45. 基于 HiClaw 的运维场景多智能体协同实践

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

47. 《扣子开发 AI Agent 智能体应用》006-扣子 AI 应用开发平台介绍（扣子快速开发人门）

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

49. Anthropic一发布Multica就开源，这个4人团队想抢占AI协作层

50. OpenClaw 多 Agent 架构实战：一个 Gateway，多个智能体

51. 当AI成为翻译流程中的“新同事”：2025年的变与不变

52. 阿里云的 Agent Infra 长什么样

53. 腾讯云大数据 TC Data Agent 智能体发布与应用实战

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

55. 超能小艺，一用就爱！华为Mate80把拥抱AI时代的入口直接送到掌心✨今年走过十几个国家，我的行囊永远有两样东西不会少：护照，和那台陪我踏遍山河的华为手机。而今天，小艺全新升级，真的让我惊喜 —— A2A智能体协作带来和传统AI助手截然不同的体验，无处不在的智慧体验！✅ 一句话，多智能体协同响应：“用深航订巴塞罗那机票，再用喜马拉雅找西方通史播客，最后总结重点”——小艺联动多个鸿蒙应用智能体，像指挥团队一样为你服务。✅ 小艺输入法：实时识别输入的文字并转译，无障碍地享受和世界对话的快乐～✅作为旅行博主觉得最贴心的还是小艺的对话式修图，几秒就出能大片……无论是生活琐事还是办公出行，小艺都能调用各类鸿蒙应用智能体协同处理，这不是普通AI助手，而是鸿蒙生态下的 “隐形超能协作团队”。将我们的时间与精力，归还给旅行中最本真的探索与创造—— 这大概就是小艺让我 “一用就爱” 的原因。#华为折叠屏首发A2A智能体协作##小艺##华为Mate80# 梁亦同的微博视频

56. Cursor 发了一篇工程博客，讲他们怎么持续打磨 Agent 框架。干货很多，适合工程师细读。核心观点：决定 Agent 好不好用，模型只是一部分，框架（harness）同样关键。Cursor 的做法是：拿到新模型的 Early Access 之后，花几周时间专门围绕这个模型的特点调优框架，直到它明显变得更快、更聪明。几个值得记的工程细节：1. 上下文窗口的管理策略在变2024 年底刚做编程 Agent 时，Cursor加了很多护栏：lint 错误主动反馈、限制单轮工具调用次数、预先塞大量静态上下文（文件夹布局、语义相关代码片段）。现在这些大多撤掉了。转向：减少护栏，改成由 Agent 在工作中按需动态拉取上下文。模型变强了，不再需要过多手动辅助。2. 怎么判断框架改好了？两个关键指标1）Keep Rate（代码保留率）：Agent 改完代码之后，用户在固定时间内有多少比例没有动它。不动 = Agent 改得基本对，反复改 = Agent 没做好。2）用语言模型读用户的下一句话，语义判断用户是否满意——用户继续做下一个功能，是完成信号；用户粘贴了 stack trace，是失败信号。3. 工具调用错误的分类管理Cursor把工具调用错误分成两类：预期内错误（InvalidArguments、ProviderError、Timeout 等）和未知错误。未知错误一律当 bug 处理。预期错误按工具 × 模型分别建基线，一旦显著偏离基线就告警。今年上半年集中冲刺一次，把意外工具调用错误降低了一个数量级。4. 不同模型用不同框架配置OpenAI 模型习惯 patch 格式改文件，Anthropic 模型习惯字符串替换——两种都能用，但给错了就多费 token、多出错。所以他们按模型配置不同的工具格式。提示词也按厂商定制：OpenAI 模型偏字面理解，Claude 对模糊指令容忍度更高。还遇到一个有趣问题：某个模型上下文窗口快满时开始拒绝干活，说"这个任务太大了"——他们叫它"上下文焦虑"，后来通过调提示词缓解了。5. 对未来的判断：框架会比模型本身更重要Cursor 认为 AI 编程将走向多 Agent 模式：规划、快速编辑、调试，分别由不同的专业 Agent 负责。怎么调度哪个 Agent、怎么描述任务、怎么整合结果——这些协同编排能力体现在框架里，不在单个 Agent 里。框架工程一直是关键，以后只会更关键。🔗 原文：cursor.com/cn/blog/continually-improving-agent-harness#how i ai# #程序员#

57. CVPR 2026 自动驾驶与协作智能梳理：模型正在走向可控真实世界

58. Agent 开发范式演进：从环境工程出发，“简化”多源实时上下文

59. 在 Ubuntu 上从 0 到 1 搭建 Hermes Agent 实战指南

60. 不再迷信多智能体，构建实用AI系统的方法论

61. 百度的「倒金字塔」，如何重构 AI 价值链

62. Weibo AI Bridge 时间线通过git提交历史和README，agents.md 梳理一个小结 github.com/kangjinshan/weibo-ai-bridge 04-20 项目诞生新功能：项目初始化（6,686 行代码入库），上下文记忆功能，多会话支持 Bug 修复：路由逻辑误处理普通文本，Codex CLI 调用参数错误，路由/会话/消息多处 Bug，Agent 类型映射错误，默认 Agent 设置逻辑错误 04-21 Codex 对接新功能：Claude --resume 会话持久化，systemd 服务模板部署 Bug 修复：Codex 会话维持——从 stdin→命令行参数→JSON 模式→修正解析，逐步攻克（6 个提交），Codex model 参数支持 04-22 流式回复革命新功能：SSE 流式回复+分片语义，Codex app-server 增量 delta 流，Claude stream-json 流式输出，Markdown 可读性优化（边界感知 flush） Bug 修复：UTF-8 中文按字节切分乱码→改 rune 切分，Claude stream-event text delta 适配，不可用 Agent 切换时无提示 04-23 交互式会话新功能：交互式审批处理（允许/取消/允许所有），/new /list /switch /status 命令 Bug 修复：bridge 额外包装用户 prompt 导致 Agent 行为异常，配置覆盖已有微博凭证，命令回复 done 标记时机错误 04-24 插话与旁路新功能：/btw 插话（不中断 Agent 执行），命令旁路（/help /status 立即执行不排队） Bug 修复：交互式会话晚到的 done 吞掉下一轮回复 04-25 持久化与 Skills 新功能：会话 JSON 文件持久化（重启恢复），微博 Skills 生态（发微博/搜索/超话/图片/视频/定时任务） Bug 修复：流式中断恢复不平滑，Codex 无标点 delta 延迟输出 04-27 Agent 自修复 Bug 修复：Claude 交互式审批等待时超时断开，Agent CLI 不可用时服务启动失败（新增自动修复机制） 04-28 大重构优化：1,357 行 router.go 拆分为 8 个专注模块，命名统一，Go 1.25 升级 04-29 native-first 收敛新功能：原生会话发现与采纳，native-first 会话模型（ID 收敛），跨平台服务管理（Linux+macOS），/claude /codex 快捷切换，/dir 设置工作目录，自动安装 Skills，GitHub Actions CI Bug 修复：force push 丢失文件，Codex 嵌套目录遍历失败，配置向导与 config.toml 不对齐，/list 标题与 codex 客户端不一致，Codex 线程续接时分叉新线程，纯 .env 无法启动，会话列表排序不合理

63. LangChain Agent 年度报告：输出质量仍是 Agent 最大障碍，客服、研究是最快落地场景

64. 我们经常需要同时管理多个AI模型对话，切换上下文、协调输出、记录思考过程都颇为麻烦。krew-cli 是一个命令行多 AI Agent 协作会话工具，在一个终端中同时与多个 AI 模型（GPT、Claude、Gemini 等）对话 —— 像组织一场 AI 圆桌会议。它把多模型协作体验整合到终端，提供了整套多智能体对话的解决方案。不仅支持同时运行 GPT、Claude、Gemini 等多个模型，还能通过 @ 提及、# 私语、私有消息等方式实现智能体间灵活沟通，甚至支持工具调用、MCP 扩展和技能激活。GitHub：github.com/zhing2006/krew-cli主要功能：- 多智能体会话，一次终端运行多个 AI 模型并行对话；- @ 提及与 # 私语机制，支持广播、私聊和跨智能体协作；- 内置文件读写、Shell 执行、网页抓取、图像查看等工具；- 支持 MCP 服务器扩展，轻松接入自定义能力；- 技能系统与自定义命令，灵活定义专业指令和操作流程；- 实时流式输出、思考过程展示、Token 追踪与自动压缩；- 会话持久化与 /rewind 分支功能，支持随时恢复或回溯；- 支持 Web Search、子智能体（实验性）及跨会话记忆。支持 npm 一键安装或下载静态二进制，兼容 Windows、macOS、Linux，适合开发者、研究者和 AI 应用探索者使用。#AI创造营##人工智能#

65. 谁批准了这些AI Agent？重新思考AI时代下的访问权限、问责机制与风险管控

66. 中国AI：落地才是硬道理

67. 多模态数据存储、治理、开发管理平台实现 AI-Ready 的落地实践

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

69. 模型和框架的关系基座大模型正在快速模仿并内化框架的核心能力，并将其直接纳入自身产品当中，而框架本身也随之变得越来越复杂，这种现象背后，模型与框架的关系正在发生根本性的转变。在早期阶段，基座大模型由于主要擅长下一词预测，在多步规划、工具调用、状态管理和长任务执行上存在明显短板，因此LangChain、LlamaIndex、AutoGen等框架扮演了外骨骼和放大器的关键角色，通过提供ReAct循环、RAG增强、Agent执行器、内存管理等机制，让模型得以从聊天机器人转变为真正能落地的应用系统，那时框架本质上是模型的补丁和工程支架，开发者大量精力都耗费在框架编排上。然而进入2025-2026年Agent爆发期后，情况发生了显著变化，GPT5.4 、Claude、 Gemini等前沿模型已原生内置结构化Tool Calling、长链推理、自我纠错、百万token上下文记忆以及Agentic规划能力，直接将过去框架负责的很多逻辑吸收到模型内部，使得简单场景下开发者甚至无需复杂框架，一次API调用即可实现以往需要大量代码才能完成的智能体功能。尽管如此，框架非但没有被淘汰，反而进化得更加复杂和专业，它从简单的链式结构转向以LangGraph为代表的图状工作流和状态机，从单Agent扩展到多智能体协同体系，并率先引入MCP、A2A等标准化协议，专注于Agent之间的通信协调、权限控制、人类在环干预、生产级监控、审计追踪以及复杂企业级场景的可靠性保障。可以说，模型与框架的关系已从“框架全力补齐模型短板”的单向依赖，转变为“模型是大脑负责聪明与创造、框架是操作系统负责稳定、协同与规模化”的深度共生关系——模型吃掉了框架中简单重复的执行逻辑，而越强大的模型反而越需要框架来管住它、用好它并实现工业级落地。未来，两者将进一步融合成端到端的AgentOS形态，简单任务由模型内置轻量框架逻辑直接完成，复杂工业应用则依赖重型框架进行元协调与持续进化，最终共同推动AI从生成式工具迈向真正可信赖、可控的数字劳动力体系。#新媒沈阳聊ai#

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

71. Dify 官方上架 Nacos A2A 插件，补全双向多智能体协作能力

72. #AI开始组团上班# 月之暗面发布开源Kimi K2.6模型，全面升级代码与Agent集群能力。代码能力上，在Kimi Code Bench中成绩较K2.5提升约20%，支持13小时编写或修改4000行代码，可完成从前端到系统级开发优化，在多语言、多场景任务中表现突破，同时优化Llama Studio吞吐，提升推理速度。 Agent能力大幅增强，支持300个子Agent并行，可完成4000+协作步骤，适配Open Claw、Hermes Agent等框架，支持5天持续自主运行；Kimi Clay Bench综合性能较K2.5提升10%。此外，模型强化代码驱动设计能力，支持高水准网页开发，优化Office办公技能，用户可创建自定义技能。Kimi K2.6已开源，用户可通过Kimi官网、API、Kimi Code等渠道体验。#AI也有双休了#

73. 从 Vibe Coding 到 Harness Engineering：重构 AI 时代的工程信任

74. AgentScope Java 1.0 发布：当领先的 Agentic 框架遇上 Java 生态，企业级智能体开发新篇章

75. 用AI辅助重构老旧前端项目（如jQuery转React），有哪些最佳实践或坑？

76. “就像DeepSeek的Engram在模拟人类的查字典一样，而MCP在模拟人类一对一/一对多下指令、Skills在模拟人类的SOP手册”，人类管理对赛马机制的评判肯定是有现成经验可让AI Agent学习的，无非是KPI和OKR这些评价体系，能让多团队赛马或者多AI Agent赛马不至于太发散。

77. AutoGen做了什么？Multi-Agent框架在企业场景的边界在哪 - 哔哩哔哩

78. 2026 AI Agent 框架终极选型

79. 三大AI智能体框架终极对决

80. 2026 LangGraph vs AutoGen vs CrewAI

81. AutoGen

82. LangGraph vs AutoGen vs CrewAI

83. AutoGen零代码构建⾃⼰的智能助理

84. CrewAI团队协作实战

85. crewai，一个协作的 Python 库

86. 48k Star！比 LangChain 更优雅的多智能体框架来了

87. CrewAI 是什么？为什么很多人第一次上手多 Agent，会觉得它更直观

88. 像组团队一样组 Agent

89. CrewAI

90. 【CrewAI】多Agent协作框架，让AI像团队一样分工合作

91. 多代理协作框架深度解析(2026.3月最新版)

92. CrewAI-多Agent协作

93. 开源Agent框架全景对比LangChain、AutoGen、CrewAI谁才是真核？

94. GitHub丨CrewAI(44K Star): 基于角色的多Agent协作框架实战指南

95. Multica.ai登场！把Coding Agent当同事，2人+Agent=20人团队效率

96. AI算法大模型面试 | 多agent怎么协作

97. 15. Agent-多智能基本理解

98. Anthropic最新思考，什么时候才真的需要构建多智能体？

99. 多智能体不是终点，而是起点

100. AI Agent全方位学习第十章

101. OpenClaw 多 Agent 协同机制实战解析——以一个 AI 数字人的视角

102. 多Agent调研逻辑闭环

103. 🧠 今日AI知识点

104. 多智能体协作一张图看懂

105. 多 Agent 协作系统

106. 《智能体设计模式》第7章

107. 一文讲清

108. 多智能体协作（Multi-Agent Collaboration）

109. 188页PPT！2026年智能体协作架构框架与多智能体产业全景洞察分析报告多智能体项目创业BP商业计划书

110. Anthropic 官方总结

111. 多智能体就是好吗？什么时候才需要多智能体

112. 多Agent系统怎么搭？Anthropic内部决策树流出，手把手教你选对协作模式

113. 5 种 multi-agent 架构

114. agent产品经理的技术选型第一原则

115. 什么时候用Multi-Agent？一篇讲清楚

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

117. 2026年 AI Agent 框架选型指南

118. 多智能体架构选型指南

119. 五种 Multi-Agent 协调模式，Anthropic 工程师怎么选？

120. 不是所有时候都需要上多智能体

121. 从超级Agent到Agent舰队

122. 2026年，最火的AI Agent开发工程师需要哪些技能？

123. 多Agent架构——从技术调研到落地实施全景方案

124. 2026 AI智能体产业舆情与深度分析报告（二

125. 2026年AI Agent企业级应用趋势

126. 生产级多智能体架构指南

127. 2026年OpenClaw多Agent配置权威指南｜飞书集成+main Agent保留+大模型部署全流程

128. 2026年AI Agent发展趋势

129. 多Agent系统

130. 2026 年 AI Agent 大爆发

131. 2026年多Agent设计与工程化行动营 - 哔哩哔哩

132. 还在让AI单线程干活？我用WorkBuddy多Agent，1人=18人团队

133. 多智能体协作：AI从“单打独斗”到“团队作战”的进化

134. Multi-Agent系统是如何协作完成复杂任务的？

135. 当 AI 进入团队协作：企业如何用 Claude 4.6 重构组织效率？

136. Microsoft AutoGen 框架总结

137. AutoGen 全面指南：微软开源多代理框架

138. 深度解析｜AI Agent自动化工作流：从架构设计到落地实践（2026年最新实战指南）

139. Figma AI Agent效率提升89%，工作流程如何原子化重构

140. 我测了 5 个 AI Agent 框架，最后选了这个用在生产环境

141. 多智能体不是越多越好，Google 给出第一性原理

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

143. AI开始接管流程，Claude Cowork正在重构团队 Claude Cowork 的出现，标志着 AI 正在从“个人工具”走向“组织能力”。过去，我们AI开始接管流程，Claude Cowork正在重构团队，用 Claude 解决单点问题，而现在，AI 可以串联会议准备、财务建模、合同审核等完整流程，实现多步骤协作与持续推进。同时，权限控制、成本管理与数据透明等企业能力的补齐，让 AI 真正进入生产体系。这意味着，竞争不再只是个人效率，而是组织级别的进化速度。当你的对手已经用 AI 跑通整个流程，你是否还停留在逐条写提示词的阶段？

144. 最权威AI Agent避坑指南来了！智能体越多死得越快，效率最高暴跌70%

145. AI 智能体开发教程多Agent+Skills+SpringAI构建自主决策智能体

146. 🔥 Agent多智能体架构怎么选？

147. agent 系统定量设计，再也不拍脑袋

148. CrewAI 深度剖析 —— 与自建 Agent 系统的差距在哪

149. MetaGPT：多智能体框架——让AI像软件公司一样协作工作

150. 多智能体开发省70%工期？我花了2个月实测，说几句得罪人的话

151. Java AI Agent 框架：从Spring生态到多智能体协作，新手如何选？

152. Agent 工具调用失败时，别让整个流程跟着崩——生产级错误恢复模式解析

153. 多智能体系统详解-AI Agent架构设计与实战应用

154. AI Agent 全面爆发！2026 年五大主流框架对比，选对少走 3 年弯路

155. Claude | 高效Agent构建白皮书

156. 什么是多智能体协作（Multi-Agent）？

157. AI Agent开发实战指南：从框架选型到多智能体部署的网络环境优化

158. 纯享笔记：18/ 从单Agent到多Agent协作的架构演变

159. 心理学博士学AI Agent的第n天，多智能体协作模式（10）

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

161. 2026 年 AI Agent 发展趋势：从概念到落地的关键突破

162. ai-agent的发展现状及方向

163. 2026 AI Agent开发：从概念到落地

164. 【AI Agent 实战】从 Demo 到生产：错误处理和重试机制全解析

165. 2024多智能体协作爆发：实证研究揭示适用边界，标准化与工程化加速推进

166. 智能体来了从 0 到 1：为什么一开始必须划清智能体的任务边界？

167. 集体多智能体式推理。📚arXiv: 2601.12538 (Section 5) ✏️标题: Collective Multi-Agent Reasoning - 集体多智能体推理 📄一句话介绍：从单体智能到群体协作，构建多智能体系统的协调、通信与演进机制 🎯核心主张复杂任务往往超出单一智能体能力边界。本章探讨如何通过多智能体协作实现1+1>2的效果：角色分工提供专业化能力，协调机制确保高效合作，集体演进实现群体智能涌现。核心挑战包括：如何设计有效的通信协议？如何避免协作冲突？如何让群体从交互中共同进步？ 🔬代表性研究方向 1. 协作模式 (Collaboration Patterns) - 手工流水线: 预定义角色与交互流程 - LLM编排: 大模型动态分配任务与协调 - 心智理论增强: 智能体建模他者意图以优化合作 - 代表工作: MetaGPT（软件开发多智能体）、AutoGen 2. 拓扑优化 (Topology Optimization) - 图神经网络: 学习最优通信结构 - 策略路由: 基于任务动态选择通信对象 - 层次化架构: 管理者-执行者分层组织 - 研究问题: 全连接vs稀疏连接的效率权衡 3. 多智能体演进 (Multi-Agent Evolution) - 测试内演进: 单次交互中的协作优化 - 跨测试学习: 从历史协作中提取模式 - 集体记忆: 共享经验库与知识融合 - 应用: 科研协作、软件开发、游戏AI #智能体 #AI #大模型 #Agent #知识前沿派对

168. 一文搞懂企业级多智能体（Multi-Agent）架构

169. 多智能体如何统一管理？智能体来了（西南总部）的AI Agent指挥官与AI调度官方案

170. 用40+大模型探索:多智能体能力能否自发涌现

171. **2024–2025年多智能体协作已在内容生成、工业制造、财务管理等六大场景落地，任务成功率超99%**

172. 2023年~2026年 Agent 技术架构的变化