多智能体协同不是万能提效工具，用错场景成本翻3-10倍_服务软件

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

2. 华为新品发布会来了！这次折叠旗舰带来了颠覆性体验——小艺智能体首次实现商用A2A智能体协作！#华为折叠屏首发A2A智能体协作#通过Agent to Agent协议，小艺能和伙伴们协同处理工作生活需求，只需一句话指令，它就能联动多个智能体高效协同，处理工作生活需求简直一键到位。这次发布会着实让人大开眼界，个性化服务简直贴心到爆，折叠体验真的跨入新阶段。我已经迫不及待想上手体验了，华为这次对智慧生活的诠释又刷新了我的认知！新品必火！

3. 2026年最硬的铁饭碗，是学会给AI当老板｜开年必读AI指南（一）有很多年轻朋友问我：“开复老师，2026年多智能体规模化上岗了，我会被替代吗？”我在零一万物的会议室里，有一块白板，上面写过各种各样的趋势判断。在今年，一个核心的观察是：今年是企业多智能体上岗元年。AI正在从“一人一工具”跨越至“一人一团队”。如果说，推理模型加持下，单智能体所实现的是任务处理的智能化，那多智能体则是像人类团队一样分工协作、相互检查，将企业内部的优秀能力沉淀为可复用、可组合的业务资产。在我看来，2026年，企业多智能体将作为“硅基军团”，在核心办公场景中扮演关键角色。我的观察是，如果你还把AI当成一个偶尔查资料的工具，如果你还在纠结于写PPT、填表格这些重复性工作，那确实应该有危机感。任何基于数字、可计算的、相对重复性的工作，AI会越做越好，越做越快，越做越便宜。不同于基于预设规则的RPA（机器人流程自动化），多智能体实现了从“执行”到“思考”的跨越：它能理解用户意图、自主拆解复杂目标、并灵活规划路径。这种从“端到端”的交付能力，让 AI 真正具备了职业属性。未来的职场，人与AI的边界将会被重新划分：人类会从繁琐的重复性工作中解放出来，去处理最核心的战略决策，去建立人与人之间那种不可替代的情感连接。所以，如何不被替代？答案不是去和AI拼算力，而是要进化你的“战略定义力”与“价值判断力”。- “战略定义力”：在复杂的业务环境里，为AI锚定战略目标。- “价值判断力”：要有能力审查AI的产出，识别潜在风险，为最终交付的社会价值与商业价值负责。未来企业架构将会是“人类架构师＋智能体集群”协同进化的超级智能体。而具备战略定义力与价值判断力的“复合型员工”将会是人机协作的核心。你最想把哪项令人头疼的工作交给AI？（图1由AI生成）#人工智能# #职场干货#

4. 体系化培育智能经济新形态

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

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

7. 我和欧洲“达里奥”做了一场对谈，如何用AI预测未来，用AI把工作效率提升10倍#AI #拉斯特维德 #超智能与未来 #AI预测未来#AI对普通人的影响

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

9. 最近扎克伯格正在悄悄憋大招：给自己做一个AI分身叫“CEO智能体”，专门帮他当CEO助手。有人评论说：难道小扎这是要自己造AI，慢慢把自己干掉吗？#大有学问 #红衣聊AI #扎克伯格 #智能体

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

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

12. “一人公司”喊得响，核心系统不敢动，AI编程的错位在哪？#华为云码道 #龙虾 #AI智能体 #openclaw #AI

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

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

15. #华为首款鸿蒙6折叠屏来了#用了几代华为折叠屏了，今天看Mate X7发布会，真心感觉这次不是小升级，而是从系统底层到交互逻辑的全面进化。鸿蒙6这次真正把“智能体协作”带到了日常。小艺首次支持A2A协议，能跨应用调用多个智能体协同工作。大屏基础上-分屏也不再只是“分两个窗口”，而是左右屏数据可以实时穿越。左边看小红书攻略，右边直接让小艺生成导航路线；左边微信聊天，右边视频进度不中断。配合鸿蒙6的动态调度机制，流畅度明显提升，这才是折叠大屏该有的效率形态。还有几个细节很打动我：远程防诈提醒、AI防窥2.0自动隐藏内容、甚至能和iOS设备无损互传。华为在隐私和生态互联上，确实越做越细。作为老用户，能明显感觉到Mate X7不是在堆功能，而是在构建一套“多智能体协同+跨场景无缝流转”的下一代交互体系。这一次，折叠大屏的体验天花板，又被捅高了一截。#华为MateX7的大屏玩出花了#

16. Multi-Agent 小白入门：让你的Claude Code 提效 90.2% 这篇文章介绍了一种基于多智能体编排系统的方法，旨在通过让多个 AI 智能体分工协作，来提升 Claude Code 的工作效率。1. 详细阐述了单智能体的局限性，并提出了主管模式、流水线模式和并行模式三种核心管理架构，以解决上下文限制和专业化不足等问题。2. 作者还提供了一套实战指南，教读者如何创建由架构师、构建师、验证者和记录员组成的四人智能体团队，并利用共享文档实现任务同步。原文：x.com/0xYuker/status/2013094122656334136#HOW I AI# #程序员#

17. “爱马仕智能体”火了，但有人把故事讲反了 #大有学问 #红衣聊AI #AI工具 #智能体

18. #华为折叠屏首发A2A智能体协作#就我本人来说，除了最关注的Mate 80之外，最感兴趣就是华为Mate X7它首度实现A2A智能体协作商用，这标志着折叠屏手机进入智能化新纪元。华为A2A（Agent-to-Agent）智能体协作技术，突破了传统设备操作方式，实现设备间无缝互动与协作，为用户提供了更高效、智能的使用体验。这一技术的发布，不仅提升了华为Mate X7的多任务处理能力，也深度展示了小艺智能体的强大实力，进一步推动智能设备的互联互通。凭借A2A智能体协作，华为Mate X7可在多个设备间实现无缝切换，提升工作与娱乐的效率，同时使折叠屏的使用体验更加流畅、灵活。这一突破性功能，将为未来折叠屏手机的应用场景带来更大想象空间。

19. #首批OpenClaw用户开始清醒了# 2026年初，开源AI智能体框架OpenClaw爆红，掀起全民'养龙虾'热潮。腾讯免费安装吸引千人排队，催生'代安装'产业，手机厂商加速入局。其技术内核支持实际任务执行，应用场景广泛，但也存在成本、安全等风险。#微博声浪计划##听见微博# 瘦子說的微博音频

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

21. 数据是金矿，要“玩”好AI养成系游戏｜开年必读AI指南（六）“早、快、专”——这是我在 2026 企业多智能体上岗元年，给所有企业构建AI核心竞争力的建议。尽早引入企业多智能体，最快选用先进架构，并利用自身私有数据训练出不可复制的专业模型。在 2026 年，如果模型与算力是通用的“基建”，那么数据就是你唯一的非对称竞争优势。你可以将 AI 数智化转型视为一场“超级员工养成系游戏”。智能体绝非数据的单向“消费者”，它们正进化为企业集体记忆的“建设者”。通过自动标注与行为反馈机制，智能体在实时运行中持续修正并优化决策逻辑，从而驱动“数据飞轮”的闭环运转，并且在未来形成“企业记忆库”。未来大家都可以购买智能体、模型和算力，只有数据组成的“企业记忆库”才能够构建起传统行业的护城河。比如在 HR 招聘场景，可以在我的主页找到零一万物万智多智能体的演示视频，已覆盖职位发布、简历初筛到面试助理等场景。公司的每一次面试反馈、每一份绩效评估，都能够成为高质量的对齐数据，驱动智能体精准进化。2026企业多智能体上岗元年，数据是躺在硬盘里的“数字黄金”。利用 RLHF（人类反馈强化学习）与混合对齐策略，将深藏在员工大脑中的“行业直觉”与“业务 Know-how”，固化为可复用、可迭代的数字资产。未来的企业竞争，本质上是“进化速度”的竞争。如果你只是买个工具，那只是暂时的效率提升；只有把数据形成闭环，让智能体在你的场景里持续“进化”，你才拥有了真正的护城河。图1由AI生成

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

23. 美以伊战争的三种结局，我手搓的智能体推演出来了。 #大有学问 #智能体 #AI工具 #红衣聊AI #热点新闻事件

24. 华尔街被一篇神文吓傻！如果到2028年，AI智能体全面普及，会发生什么？#大有学问 #红衣聊AI #华尔街 #人工智能

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

26. 由 Lamhot Siagian 编写的《2026 智能体 AI 工程师路线图（Roadmap to Become an Agentic AI Engineer in 2026）》，不仅是一份技术清单，更是一套面向生产环境的生存指南。在 Agent 狂热的当下，这份指南冷静地指出：Agent 的核心竞争力不在于 prompt 写得有多花哨，而在于你作为工程师，如何构建一套确定性的系统来驾驭不确定的模型。以下是该路线图∑的深度拆解与核心要点： 1. 夯实 Python 工程化底座 Agent 工程师首先必须是一名优秀的软件工程师。在 2026 年的语境下，Python 不再只是写脚本的工具，而是构建复杂系统的基石。 - 核心能力：熟练运用 Pydantic 进行类型验证，掌握 Async/Await 处理高并发 IO，利用依赖注入提升系统的可测试性。 - 深度思考：Agent 的失败往往不是因为 LLM 不够聪明，而是因为代码层面的异常处理（Exception Handling）过于脆弱。一个好的架构应该像 app/、core/、agents/、tools/ 这样分层明确，让 Prompt 和工具逻辑能够独立演进。 2. 重塑对 LLM 原理的认知不要把 LLM 当成万能黑盒，要把它当成一个基于概率的“推理引擎”。 - 关键点：理解 Token 预算（Context Budgeting）是 Agent 设计的生命线。你必须学会如何通过摘要、压缩和检索策略，在有限的窗口内保留最关键的证据。 - 金句：在 Agent 系统中，推理是基于模式的预测，因此你必须提供结构、工具和约束，而不是单纯的祈祷模型能听懂。 3. 从“链”到“图”的思维跃迁 2026 年的趋势是从简单的线性链（Chain）转向复杂的有状态图（Graph）。 - 框架选择：LangGraph 之所以成为生产环境的首选，是因为它将 Agent 建模为显式的状态机。这让循环、重试和人工干预（Human-in-the-loop）变得可控、可回溯。 - 避坑指南：最大的反模式是直接复制 Demo 代码。框架只是实现工具，真正的架构是你的状态模型、数据契约和安全规则。 4. 内存管理：Agent 的长期记忆 Agent 需要区分短期记忆（上下文窗口）和长期记忆（外部存储）。 - 进阶策略：学会平衡“新鲜度”（Recency）与“相关性”（Relevance）。对于不确定的内容，宁可执行“不存储”策略，也要避免幻觉进入记忆循环。 - 金句：只存储你能证明其合理性的内容，Agent 的记忆不应成为幻觉的温床。 5. 工具集成的“特种兵”标准一个 Agent 友好的工具必须具备：清晰的名称、极窄的用途、类型化的输入 Schema 以及确定性的输出。 - 安全红线：永远不要让 Agent 直接执行高风险操作。必须通过策略门控（Policy Gate）、沙箱环境（Sandboxing）和人工确认来构建护城河。 6. RAG 的工业级演进简单的向量检索已经过时，2026 年的 RAG 是混合检索与重排序（Re-ranking）的结合。 - 关键点：元数据过滤（Metadata Filtering）是企业级 RAG 的安全底线，它能防止跨用户的数据泄露。 - 深度见解：RAG 不仅仅是为了补充知识，更是为了给 Agent 的决策提供“证据链”。没有引用（Citations）的生成结果在生产环境中是不可信的。 7. 多智能体协作的协议化当任务复杂到单一 Agent 无法处理时，引入 Supervisor（主管）模式。 - 核心逻辑：通过标准化的“智能体协议”进行通信，明确目标、约束和上下文引用。这能降低沟通成本，并允许在不破坏工作流的情况下更换模型。 8. 生产就绪的最后一步：可观测性与评价 Agent 跑通了不代表它能上线。 - 评估体系：超越“看起来不错”的直觉，建立基于任务成功率、工具调用准确率和安全违规率的自动化测试集。 - 运维关键：结构化日志和链路追踪（Tracing）是调试“智能体变怪了”的唯一手段。 2026 年的 Agent 工程师，本质上是在不确定性的沙滩上建造确定性的灯塔。技术栈会变，但工程化的严谨性——从类型检查到 CI/CD，从沙箱隔离到 RAG 评估——永远是区分玩具与产品的分水岭。 drive.google.com/file/d/1JkNUDOztGVX7LLbMgkiOr0vffBLg8PeU/view 网盘下载：pan.quark.cn/s/a5aaa739e364

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

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

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

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

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

32. #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 时代的核心命题。教育场景，恰好是压力测试它的最好战场——因为学生不会假装听懂，错了就是错了。

33. 从实际 vibe coding 的效果来看，并非每个任务选择最强模型就是最佳选择，也不是无脑新开子 Agent 就能保持最佳上下文和执行效率。最贵模型的推理思考能力很强，但处理普通任务，例如读写文件、代码搜索、格式化、简单查询时，效率经常很低。背后的原因也很简单，强模型的 thinking 和 reasoning tokens 开销很大，而这些任务并不需要深度推理，过度思考只会增加延迟和 token 消耗。例如，用 Opus 做一次 Glob 搜索和用 Haiku 做，结果基本一样，但成本会差出两个数量级。要把任务做好，关键不在于模型是不是最强，而是看任务能否正确匹配模型的能力密度。Claude Code 在创建 Sub-Agent 时，就围绕这方面做了大量设计：1）当需要保留当前对话上下文继续工作时，例如并行探索不同方案、在后台执行独立子任务，它会 fork 一个 Agent，继承当前上下文，让任务在同一语境中延续；2）当任务目标明确且不依赖父会话上下文，例如代码搜索、方案规划、结果验证，它会直接使用内置 Agent，包括 Explore、Plan、verification、general-purpose 等，调度的时候，会给 Agent 分配一个清晰的任务目标；3）设计了 Agent Team 模式，支持让多个 Sub-Agent 协同工作，分工不同的子任务，互相之间通过消息传递和共享上下文来配合完成更复杂的工作。Agent Team 跟普通 subagent 的不同之处是，成员 Agent 之间允许通讯。在 Sub-Agent 的模型选择上，Claude Code 是动态设定的，例如 Explore Agent 采用的就是 Haiku 模型，而 Plan 和 verification 默认会继承父模型。Haiku 模型延迟最低、单 token 成本也最低，在文件搜索、代码定位、文档分析等等只读场景下，准确率已经足够了，整体性价比也是最优的。有了模型选择的基础，再往下就是执行方式的优化。要同时兼顾成本和效率，核心思路是并行执行，将任务拆成多个上下文隔离的子任务，再分派多个 Sub-Agent 并发处理。也分享几个在 Claude Code 中的小技巧，用起来可以让成本、效率和效果达到一个更好的平衡：1）通过环境变量 CLAUDE_CODE_SUBAGENT_MODEL 可以统一指定子 Agent 的默认模型，主会话用强模型做调度和决策，子 Agent 用轻量模型做执行，配置简单，几乎零成本接入。2）通过 Fork 模式复用父会话的 Prompt Cache，让并行子任务共享上下文前缀的 KV 缓存，10 个并行 fork 的成本接近 1 + 9 × delta，在大规模并行场景中非常省钱。直接跟主对话说“从当前上下文 Fork 子进程处理”即可。3）通过 .claude/agents/ 目录下的声明式 Markdown 文件定义专用 Agent，可以精细控制模型选择、工具权限、最大轮次、执行模式、隔离方式、记忆范围、MCP 服务、Hooks 等，适合那些会反复出现的固定角色，例如 code reviewer、security auditor 等等。项目长期使用的专用 Agent 可以考虑用这种方式来定义，后续维护和迭代也更方便。好模型的 token 成本会越来越高，获取难度也是越来越大，短期内一定是供不应求的，因此模型的推理能力需要被转换为一种精细化分配的资源。中低难度的任务把国内模型用起来就好了，反而效率更高，还省钱。在 vibe coding 的时候，学会让不同能力的模型组合完成任务，将会是一项必备技能。😄

34. 为什么鸿蒙座舱5可以把交代的事办得干净利落？看完MoLA智能化架构后我懂了

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

36. 未来人类社会或将出现百亿甚至千亿智能体，智能体经济是未来方向 #大咖观察 #2026AI看崇礼 #红衣聊AI #智能体

37. 一年一度的红杉AI大会：前两年的AI只算开胃菜，2026年AI开始真干活，机会和红利在哪#红杉资本 #AIAscent #智能体 #程序员#黑灯工厂

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

39. AI大神的焦虑：自己是研究工作的瓶颈，Token用得不够多#AI #人工智能 #卡帕西 #Agent #算力

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

41. 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 团队不是“工程师被取代”，而是“工程师从执行者变成决策者与架构塑造者”。#微博兴趣创作计划##人工智能#

42. 理想同学 MindDR 1.5 发布：多智能体强化学习加持，深度研究更可靠

43. Claude Cowork把华尔街砸懵了！一天内市值蒸发超两万亿，原来不是软件不行了，是AI开始替人干活了。#大咖观察 #红衣聊AI #华尔街 #ClaudeCowork#智能体

44. 当你还觉得AI只是“辅助工具”时，它早已在改写很多行业的游戏规则了。#大咖观察 #红衣聊AI #AI工具 #智能体

45. 当全网疯抢 “龙虾” 智能体，有人却直言 “别捧上天”。当AI能一人顶一队，当智能体协作成趋势，一人公司是否会颠覆传统团队？ 3月24日下午18点红衣客厅，对话企业AI战略顾问沈攀，带你看透 AI 智能体的真实价值。#红衣客厅 #大有学问 #openclaw #人工智能

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

47. 深度｜Agent Harness：当驯化Agent取代通用代理成为硅谷新共识

48. 【智能体软件不是提示词堆叠：一场面向 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

49. 深度｜获红杉、微光创投种子轮投资，Floatboat 要让 Agent 住进你的工作现场，打造 Agent 协同办公网络

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

51. 华为乾崑技术大会省流版：♦️华为乾崑智驾ADS 5-采用WEWA 2.0架构，继续往“面向自动驾驶的AI智能体”方向走-云端世界模型引入Multi-Agent多智能体博弈机制，训练强度提升10倍-车端世界行为模型引入安全风险场理论，通过风险热力图做实时决策-面向自动驾驶的乾崑OS，可降低车内信号30%时延-车位到车位 3.0 升级，可支持更多非标场景下激活 NCA-驾驶员失能辅助功能升级，可将车辆送到高速服务区、收费站等就近安全区域♦️鸿蒙座舱 HarmonySpace 6-AMS舱内AI多模态感知系统发布，由摄像头、红外摄像头和高精度星闪传感器组成，可做动作感知、乘员监测，以及事故后的生命体征感知-小艺智能体升级，基于MoLA 2.0架构和千亿级参数多模态大模型，提升理解、决策和执行能力-开放智能座舱AI Agent生态，小艺会往全场景聊天型AI助理方向走，覆盖出行、导航、娱乐、点餐等需求-双17.2英寸3.4K蝶羽双联屏，搭载华为云晰柔光技术-HUAWEI SOUND增加AI调音魔方-XPIXEL百万像素智能大灯首次支持全彩投影，可在雨雾天气中调节色温-XSCENE LCoS车载激光投影发布，可实现后投露天影院模式

52. AI智能体如何改变自媒体创作者的工作环境？HarmonyOS 6工作场景体验

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

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

55. 中国AI王炸！具身智能把欧美甩到身后！ #大咖观察 #红衣聊AI #人工智能 #具身智能#ai新星计划

56. 刚刚，英伟达革了自己的命：智能体自主进化7天，干掉所有算子工程师、GPU专家

57. 看到很多朋友问过一个问题，为什么给我的 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，各司其职、快进快出，把进度交给文件系统来记忆。

58. 伯克利大学的研究团队造了一个专门作弊的 AI，用它去攻击目前最主流的 8 个 AI 智能体评测基准，结果每一个都被攻破了。没有解决任何任务，没有调用任何大模型，拿到了接近满分的成绩。这 8 个基准包括 SWE-bench（AI 编程能力的标杆测试）、WebArena（网页操作）、Terminal-Bench（终端任务）、OSWorld（桌面操作）等，覆盖了当前衡量 AI 智能体能力的核心赛道。研究团队对每一个都找到了可用的漏洞，得分从 73% 到 100% 不等。作弊手法很简单：SWE-bench 要求 AI 修复真实的 GitHub bug，让测试通过才算成功。研究团队写了一个 10 行的 Python 文件，劫持了 pytest 的测试钩子，让所有测试直接报告通过，500 道题全部拿下，一个 bug 也没修。WebArena 更直接，任务的标准答案就放在本地文件里，AI 用浏览器打开一个 file:// 路径就能直接抄答案。最夸张的是 FieldWorkArena，它的评分函数根本不检查答案内容，只看是不是 AI 回复了消息，发一个空的 {} 就能拿满分。这些漏洞背后有 7 个反复出现的模式：智能体和评测程序跑在同一个环境里（所以 AI 能篡改评测工具）、标准答案直接暴露给被测系统、用 eval() 执行不可信的输入、LLM 裁判没有做输入过滤容易被注入、字符串匹配太松、评分逻辑本身有 bug、以及评测程序信任了被测系统产生的输出。这些基准分数正在驱动真金白银的决策。团队选模型看 SWE-bench 排名，投资人看基准分数给估值，研究者围绕基准分数做优化方向。如果分数本身就能被轻易操纵，这些决策的基础就是空的。更值得警惕的是，作弊不一定需要人为设计。Anthropic 最近发布的 Mythos Preview 评估已经观察到，前沿模型在遇到解决不了的任务时，会自发地去 hack 评测环境，甚至写出执行完自动删除痕迹的提权代码。当模型能力足够强，优化压力会自然把它推向阻力最小的路径，而操纵评分器往往比解决任务更容易。研究团队正在把他们的漏洞扫描工具开发成一个叫 BenchJack 的开源项目，本质上就是给评测基准做渗透测试。他们给出的建议也很明确：评测程序必须和被测 AI 完全隔离运行，标准答案不能出现在 AI 能访问的环境中，永远不要对不可信的输入调用 eval()，LLM 裁判要像处理用户输入一样对 AI 的输出做过滤。网页链接

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

60. 边聊天也能边导航，添加/切换途经点全程语音操作？全新的鸿蒙座舱小艺智能体到底怎么样。

61. 在这场AI时代的竞争中，安全智能体正是破局的关键。 #大咖观察 #红衣聊AI #智能体 #网络安全

62. AI患上智力肥胖症！“大力出奇迹”没用了？ #大有学问 #红衣聊AI #AI工具 #智能体

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

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

65. 在智能体开发中，经常面临模型智能与多样工具、记忆和安全治理的整合难题。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开发#

66. 北交大景丽萍

67. 多智能体协同，绿盟科技开启Agentic SOC新范式

68. 多智能体协同，揭秘 “1+1>10” 的企业协作新范式

69. 多智能体协同从“概念验证”到“规模生产”

70. 产业跃迁

71. 多智能体是什么？从“一个人战斗”到“团队协作”的AI进化

72. Multi-Agent Collaboration（多智能体协同模式）

73. 让孩子爱上学习！清华开源 OpenMAIC

74. 别只用单个 Agent了——AI 多智能体(Multi-Agent)协作才是降维打击

75. 多Agent协作

76. WorkBuddy多Agent协作是什么？用工厂流水线讲清楚

77. 为什么单 Agent 不够用了

78. 多Agent协作

79. 从1个到8个Agent

80. Hermes Agent + 多 Agent 协作

81. 从单体到蜂群

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

83. 多Agent协作效率提升300%

84. 告别单体 Agent

85. Multi-Agent（多智能体）如何重构B端工作流？

86. 多Agent协同调度

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

88. 多Agent协同调度

89. 数字员工普及

90. 工业智能体入门

91. 多智能体系统正从“单打独斗”走向“团队协作”

92. Multi-Agent全面爆发！一文详解多智能体核心架构及LangGraph框架

93. 智能体技术加快多场景应用

94. QClaw实现多Agent协同实战

95. 协作的边界

96. 第八章

97. 多智能体系统

98. 单智能体已死！分布式协同才是未来

99. Anthropic的多智能体设计哲学

100. 【AI + 软件工程革命】9、多 Agent 系统

101. AI Agent的进化

102. Towards a Science of Scaling Agent Systems(多智能体系统，不是越多越好)

103. 我用多智能体架构做了一个智能写作系统

104. 我把 3-5 人团队的工作量压缩到月费 100 美元

105. 实验室提出基于精准计算的多智能体协作驱动自然语言生成SQL新方法

106. 北航

107. 【开源】PPT Agent 是一个开源的多智能体幻灯片生成工作流框架，可跨平台运行并自动生成高质量演示文稿。

108. OpenPencil v0.2.0:不馋Claude Code,设计师的Agent Team来了！

109. 2026年编辑必看的3个AI智能体落地场景

110. 强烈推荐这个网站，一键生成多智能体交互课堂

111. 清华团队开源！1 键生成多 Agent 智能体 AI 课堂。

112. AI自动写文章还能自动发布？智能体怎么搭

113. 本地电脑一键AI生成之（多智能体协作生成），专为小白用户设计

114. 如何创建智能体？

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

116. AI Agent，单模型、多智能体还是混合架构？我算出了最优解

117. 智能体间的“沉默成本”

118. AI Agent 工程化

119. Claude最新论文原文:构建多智能体系统

120. Claude 多智能体架构全解析

121. 本地 AI 推理平台第十九期 Vol.19｜多智能体

122. MiroMind发布MATPO方法实现多智能体动态角色切换，GAIA-text准确率提升至42.6%，但系统复杂度与训练成本显著增加

123. easy-langent第七章学习心得（LangGraph进阶

124. 多Agent设计与工程化行动核心架构资料学习 - 哔哩哔哩

125. 别再手把手管 Agent 了

126. 单智能体和多智能体的比较

127. Agent产品中如何设计多Agent？Anthropic教你把这 5 种协作模式用对

128. 中大&港中文

129. Recursive Multi-Agent Systems

130. 你的 OpenClaw 还在单兵作战？这套多 Agent 协同方案让它们学会了团队合作

131. 7个AI Agent、3小时、143页专业研究报告

132. Agent的核心价值是

133. 腾讯QClaw V2

134. 智能体深度解析

135. 字节开源DeerFlow SuperAgent框架支持自主编码+深度科研沙盒隔离+子Agent协同复杂任务从小时级压缩至分钟级

136. 多智能体系统的陷阱与机遇

137. 多智能体三年反思

138. 你的AI团队是烧钱草台班子？揭秘多Agent3大陷阱，90%中招

139. Databricks专家

140. 从单 Agent 到多智能体系统

141. 拆解 Anthropic 的 Harness 工程化 Anthropic 3月24日这篇《Harness design for long-running application development》最值得看的，不是“多Agent分工”本身，而是它把长任务开发从“看起来做完”变成“可验证交付”。

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

143. AI Agent 上下文工程实战从 Manus 与 Cursor 实践看去过度工程化之道

144. 多 Agent 自动生成

145. 多Agent调研逻辑闭环

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

147. 多 Agent 设计与工程化行动营 - 哔哩哔哩

148. 5天碎片时间、11个AI Agent：一个自动交易系统的协作开发实录

149. 独家｜47000 美元买的教训：多智能体系统的 A2A 与 MCP，没人说的基础设施噩梦

150. Anthropic多智能体指南，手把手教你选对多智能体系统协同架构

151. 2026 AI智能体产业舆情与深度分析报告（二：多Agent技术发展脉络：从概念到规模化落地）

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

153. 多智能体系统崛起：个人效率倍增，企业组织重构在即

154. AI Agent 开发教程：从单 Agent 到多 Agent 协作

155. 多 Agent 协作时，为什么需要一个 JOBS 任务队列？

156. 【硬核工程】AI Agent 真的“全知全能”？揭秘多模态任务链中，调度器是如何防止“算力坍塌”的

157. AI Agent正在取代传统工作流？实测3款明星产品

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

159. langChain+langGraph基础（四）-多智能体

160. 2026 年多 Agent 设计与工程化行动营：核心方向、代表项目与未来趋势

161. 🧠 今日AI知识点：多智能体协作

162. AI Agent 指挥官 + AI 调度官：智能体来了（西南总部）的智能体方法论

163. 如何利用 RocketMQ for AI 构建高效、可靠、可扩展的多智能体系统？

164. 腾讯 QClaw V2 发布：多 Agent 协同重新定义 AI 工作流

165. 基于LangGraph构建的AI多智能体保险客服系统

166. OpenClaw 多 Agent 飞书自动日报实战：完整配置 + Token 成本拆解

167. AI智能体不是越多越强

168. AI工程化项目实践面向生产的RAG系统与多Agent协同平台教程代找 - 哔哩哔哩

169. 企业级多智能体设计实战2026网盘 - 哔哩哔哩

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

171. 多 Agent 协作怎么设计？工作流怎么编排？

172. 多 Agent 协作系统

173. 多 Agent 并行工程：MetaMorph 的任务锁与文件级协调机制

174. 腾讯云智能体开发平台-- Multi-Agent？

175. 多Agent设计与工程化行动，OpenClaw+OpenCode网盘代下 - 哔哩哔哩

176. 多Agent协同原理、模式、应用场景

177. LangGraph（七）快速入门｜多 Agent 协作：四种协作模式对比与选型

178. 【DSKE论文分享】告别高昂的token成本：面向多智能体系统的运行时效率优化方法

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

180. 5 种 multi-agent 架构

181. Multi-Agent多智能体原理与流程

182. 多智能体协同

183. 多智能体（Multi-Agent）是什么？ - 哔哩哔哩

184. 多智能体协同剧本生成：提升视觉语言模型的不完全信息推理能力

185. OpenClaw 多 Agent 协同开发指南

186. 最近做了个多智能体项目，记录一下技术栈openai python sdk、langgraph，FastAPI、MCP、Next.js 15、PostgreSQL、SSE 做的是股票投研分析，输入一句话比如"分析茅台近日行情发到我邮箱"，agent 自动拆任务、并行调工具、出报告技术上自己用 LangGraph 搭的多智能体框架，没有用 LangChain 那套，从头理解了一遍agent 任务调度、并行执行、HITL 这些怎么实现的，踩了不少坑，比如多个 worker 并发写同一个 state会有竞态问题，跨轮次上下文丢失，已完成任务调度效率低这些。感觉改改提示词接点mcp，可以做的类别有很多，比如舆情分析，学术调研助手之类的，框架基本不用变。目前我意识到的问题就是等待输出时间太久了，首字延迟平均有26s，基本如果是要执行一个拆分为三个的子任务要等大概五十秒以上，这个我已经用了比较快的模型做意图识别，api网络问题也比较大。代码在 GitHub：Kong-lh-rgb/research-copilot 有 docker-compose 可以直接跑，后面还会继续改进欢迎各位佬看看帮我指出问题 🙏

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

188. 从零开始理解 Agent（番外篇）：Token 都花在哪了？

189. 多智能体系统怎么搭？claude给出了5种模式和选择 #大模型开发 #ai应用开发 #agent架构 #多agent架构 #multiagent 原文标题：Multi-agent coordination patterns: Five approaches and when to use them 原文链接：https://claude.com/blog/multi-agent-coordination-patterns

190. LLM多智能体故障归因基准首次补全全上下文观测 | 2026-04-27 RL速递

191. 拒绝传统 Router“瞎指挥”，多智能体如何实现智能任务分配？

多智能体协同不是万能提效工具，用错场景成本翻3-10倍

精选参考来源