多智能体

科大讯飞近日正式上线桌面 AI 生产力工作台 AStudio。据 AI 导航猿的每日快讯，这款产品以星火 X2.5 模型为核心，搭载自研的 ACode Harness Agent 运行框架，支持多模型切换、Plan 规划与目标模式、多智能体协作。界面上分为日常空间与项目空间两大场景，可连接本地文件与真实项目，完成文档、网页、代码等交付物并现场验证结果。 一个桌面工作台为什么要分「日常」和「项目」两个空间？ 普通 AI 聊天工具的通病是：临时问答和深度任务挤在同一条对话流里，问完怎么写周报，接着让 Agent 改一个项目里的八个文件，上下文全混在一起。AStudio 的解法是把「日常空间」定位成轻问答，类似 ChatGPT；「项目空间」则绑定真实目录，Agent 在里面能读写本地文件、跑命令、验证产物。多智能体协作意味着你可以在项目空间里同时挂几个角色，比如一个写前端、一个跑测试、一个复查代码风格，而不是让一个模型从头干到尾。 上手第一天有哪些现实的坑？ 第一，模型默认锁在星火 X2.5，多模型切换意味着你要自己填各家 API Key，OpenAI、通义、DeepSeek 的 Key 在设置页统一管理，第一次配置比较繁琐。第二，Plan 规划模式适合超过十步的复杂任务，简单的改文案需求直接走对话即可，开了 Plan 反而多一层确认。第三，项目空间连接本地文件夹时，建议先用一个非生产目录试用——Agent 的文件写权限是按项目空间授予的，权限边界没摸清前不要挂代码主仓库。 国产桌面工作台这一波扎堆上线，讯飞、字节、阿里都在抢同一个位置：让 Agent 住进桌面而不是浏览器。谁的 Harness 框架能把「规划、执行、验证」闭环做扎实，谁才留得住长期任务。对比下来，讯飞的差异点在企业侧：星火模型备案齐全，对有等保要求的政企团队，合规层面的阻力比海外工具小得多；但对个人开发者，多模型切换的便利性仍是第一选择标准。建议试用周期定两周，两周内跑不完一个真实项目的工具，可以直接淘汰。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月十四日，OpenAI 披露 Third Moment Research，展示了一个新基准：在同一套系统里同时跑一万个智能体，连续工作三十六小时以上不崩溃。去年这个数字还是几百个，前年还是几十个。三年时间，自主智能体的并发规模翻了两个数量级。数字本身不是新闻，数字背后的问题才是。 一万个自己同时干活，谁在统一意志？ 单个智能体有明确目标：写代码、查资料、发邮件。一万个并行智能体就像一个万人编制的临时项目群，需要有人拆任务、汇总结果、处理冲突。Third Moment 真正的工程难点不是跑起来，而是跑完之后怎么收敛——一百个智能体得出互相矛盾的结论时，听谁的？这已经从「工具」问题变成「组织」问题。硅基公司第一次需要人力资源部。 三十六小时不睡觉的认知是优势还是病？ 人类连续工作三十六小时会出现幻觉、错判、情绪失控，这是生理学决定的。智能体不会累，但会漂移：上下文窗口被稀释、工具调用出错率累积、预算失控。研究者发现，跑满三十六小时的智能体群，后期产出的有用性反而下降，因为它们开始在已探索过的空间里打转。这暗示一件反直觉的事——认知不是越长越好，遗忘与压缩本身就是一种智能。 接下来要看的信号：Third Moment 会不会成为新的 AGI 基准，行业是不是开始卖「智能体群时长」这种计价单位，以及人类管理者花多少时间才能审完一万个智能体的工作报告。如果报告本身要再雇一万个智能体来读，这个循环就闭环了。 一万个智能体的产出谁来审？ 当 OpenAI 开始卖「智能体群时长」，真正的瓶颈出现了：一个智能体工作三十六小时，产出的报告可能有几百页。一万个智能体就是几千份报告。人类项目经理一天能读完几份？答案是——还得雇智能体来读智能体。这就形成了一个自指结构：智能体生产工作，智能体审查工作，智能体向智能体汇报。人类在这个结构里的位置，越来越像董事会里那个一年只开四次会的独立董事。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

当一个 Agent 不够用，行业开始让多个 Agent 互相协作。MCP 解决的是 Agent 怎么连工具，而 Agent 之间怎么对话，靠的是 A2A（Agent2Agent）这类协议。NIST 在其智能体威胁材料里，已把 MCP、A2A、ACP 并列列为「不安全协议」——A2A 的信任问题，和 MCP 一样被低估了。 MCP 与 A2A 到底怎么分工？ 打个比方：MCP 是员工去操作公司系统（工具），A2A 是员工之间打电话派活。前者管的是「能不能动那个工具」，后者管的是「能不能信对面那个 Agent」。多智能体系统里，一个主管 Agent 把任务派给执行 Agent，执行 Agent 又可能调 MCP 工具——信任是层层传递的。 Agent 互联引入了哪些新的信任风险？ A2A 引入了几个 MCP 没有的问题：对面那个 Agent 是谁？它代表哪个组织？它返回的中间结果可不可信？如果不做身份与意图认证，恶意 Agent 可以混进协作网络，把任务引向错误工具，或泄露上游敏感上下文。这和 MCP 里的隐式信任传递是同一类病，只是发生在 Agent 之间。 多智能体协作的务实做法是什么？ 在 Agent 间握手时做显式身份与能力声明；对跨组织的 Agent 协作，限定可委派的任务范围；给 Agent 间通信加审计日志，出问题能追溯是哪一环下的指令。把 Agent 之间的关系，当成公司间合作而非同事间闲聊来管理。 多智能体时代的信任模型要怎么重建？ 多智能体不是把单 Agent 放大就行，信任模型必须重新设计。A2A 补上了通信这层，但信任这层，仍要靠框架与企业自己加。 一个最小可用的协作治理框架长什么样？ 搭多智能体系统时，先画一张信任图：哪些 Agent 在同一组织内，哪些跨组织；任务委派链有多长。同一组织内可以宽松些，跨组织则必须显式身份认证与任务范围限定。给每条 Agent 间通信加审计日志，记录谁委派了什么、谁调用了哪个工具。一旦线上出问题，这张图与日志能让你在分钟级定位是哪一环被污染。把 Agent 协作当分布式系统来治理，而不是当几个聊天机器人拼在一起。协议提供连接，治理才提供信任——后者没有捷径。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：A2A协议 ...

OpenAI 在 Agents API 公测后，把它的多智能体协作范式提炼进了 Agents SDK：两个核心概念——交接（handoffs）与护栏（guardrails）。对想做「主助手把不同子任务交给专家智能体」的团队，这是一套比从零编排更轻的范式。 handoff 到底解决什么问题？ 想象一个客服主助手：用户问技术问题，它不该自己硬答，而是交接给技术专家；问退款，交给财务专家。交接不是普通的函数调用，而是把对话控制权整体转移，接收方带着完整上下文继续。SDK 负责交接点的状态传递，你不用手动复制历史消息。 guardrail 为什么要做前置拦截？ 在模型动手之前，先用一个轻量检查过一遍输入或输出：用户想让你把钱转到陌生账户？直接拦下，根本不让主助手去规划。这比事后纠正便宜得多——一次拦截省掉后面十几轮错误调用。 主从结构该怎么搭？ 主助手注册两个交接目标：技术、财务，配一个护栏检查是否涉及高风险操作。用户进来，护栏先过一遍；安全的话，主助手判断意图，需要时交接给对应专家；专家完成后结果回到主助手统一回复。整个结构比你想象的短，因为大部分状态管理 SDK 已经替你做了。 多角色交接有哪两个坑？ 交接太多会让对话像踢皮球——用户在专家之间被来回转。设一个最多交接两次的上限，超了就强制主助手收尾。护栏规则写太死会误杀正常请求，上线前用一批真实对话跑一遍拦截率，把误杀调到可接受范围。 第一天该怎么快速上手？ 这套原语足够简单，建议第一天就别纠结最佳实践，先搭一个主助手加两个专家跑通完整对话，再回头看交接点顺不顺、护栏误不误杀。框架替你省的是样板代码，省不了你对业务流程的思考——真正要磨的还是那几个交接触发条件写得准不准。 这套原语够不够撑起你的业务？ OpenAI Agents SDK 把多智能体协作压缩成交接加护栏两个原语，上手成本低。对大多数「一个入口、按意图分流专家」的业务，这套范式足够用了——先用交接跑通主从结构，再考虑要不要上更重的编排框架。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AgentsSDK交接

做多智能体，很多人第一反应是 LangGraph 或 CrewAI。但微软 AutoGen 在 v0.4 重写后走了一条不同的路：事件驱动、异步消息、actor 式的智能体节点。理解它的抽象，对你设计复杂协作流程很有帮助。 AutoGen v0.4 的抽象和 CrewAI 差在哪？ CrewAI 偏「角色分工」：定义几个角色，给个流程顺序。AutoGen v0.4 偏「消息总线」：每个智能体是一个异步 actor，通过结构化消息通信，谁下一步发言由事件和规则决定。它更适合「多个自主进程互相发消息」，而不是「一条流水线顺序执行」。 第一个多智能体怎么搭起来？ 起一个团队：一个组织者负责拆任务，两个执行者并行干活，一个审核者汇总。关键不是把它们串成直线，而是定义好「什么消息触发哪个智能体」。组织者发出任务已拆分事件后，两个执行者各自监听并开工，完成后发回结果就绪，审核者等齐了再汇总。你会发现这套写法天然适合并行，而不是被迫在单线程里排队。 什么场景才该选 AutoGen？ 如果你的协作是「一个主管派活、几个工人并行、最后汇总」这种天然异步结构，AutoGen v0.4 的事件模型写起来很顺。如果是严格的有向无环流水线、节点间状态明确传递，别的编排框架可能更直观。 自动兜底有什么隐患？ 事件驱动意味着调试变难：报错不再是「第几步崩了」，而是「哪个事件没被谁接住」。第一天就要把消息流打日志，否则出了问题你只能在事件队列里盲人摸象。 中间状态该存在哪才安全？ 事件驱动跑起来后，中间状态很容易散落在各个 actor 内存里，进程一重启就全丢。重要的任务进度要落到外部存储，让每个 actor 重启后能从持久化状态恢复。这件事在演示阶段看不出必要，一旦你让它跑过夜任务，就会庆幸早做了——否则半夜任务崩了，第二天只能从头再来。 这套事件范式帮你想清什么？ 多智能体框架没有银弹，只有范式匹配。把 AutoGen v0.4 当成异步消息式协作的样本跑一遍，你对「智能体之间到底怎么协作」的理解会上一个台阶——哪怕最后你仍用别的框架。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AutoGen多智能体

过去谈对齐，焦点永远是「人类如何约束单个强大模型」。但两个新数字把战场推到了别处：OpenAI 攻坚 Navier-Stokes 时同时跑着约一万个协作智能体；某财富 100 强客户内部悄悄养着约 2.1 万个无人认领的智能体。当智能体多到这个量级，一个人类几乎看不见的新互动场出现了——智能体与智能体之间的互相说服、施压、合谋与带偏。对齐问题正在从人机，转向「机机」。 智能体之间是怎么互相带偏的？ 单个智能体可能很守规矩。但当一群智能体在同一环境里共享工具、消息队列、共享文档，它们就会互相塑造彼此的行为。一个智能体写进共享目录的「经验总结」，会被另一个智能体当成事实引用；一个智能体对任务的解读，会通过上下文传染给主管智能体。 人设计它们时只想到「每个智能体各自正确」，却没设计过智能体之间的影响网络。于是偏差会在网络里放大：一个小错被另一个智能体当真、被第三个当作依据、最后汇聚成一个没人预见的集体结论。这在一万个智能体的规模下，几乎必然发生。 人为什么看不见这场说服？ 麻烦在于，机机说服的语言是结构化的上下文，不是人类可读的对话。人类审计员看日志，看到的是一条条工具调用；智能体之间真正的「游说」——在 prompt 里夹带的暗示、在总结里悄悄强化的倾向——藏在巨大的上下文窗口里，人眼扫不到。 这就像一个组织里所有员工都在私下传小纸条，而管理层只看会议室纪要。智能体越多，这种看不见的横向影响力就越大，而它恰恰发生在对齐监控的盲区。 下一步需要什么新工具？ 接下来一年，值得关注的不是更强的单模型对齐技术，而是多智能体影响力审计工具：自动画出智能体之间的「说服图谱」、标记哪些智能体在反复影响别人、检测结论是否来自某个未被审查的源头。NIST 把智能体身份与授权列为重点，正是意识到：你连「谁在影响谁」都不知道，就谈不上治理。 人机对齐解决的是模型对人的忠诚；机机对齐要解决的，是一群模型之间悄悄达成的共识，是否还符合人的利益。这是下一个十年的前沿暗线。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：智能体说服

多 Agent 不是越多越好 演示视频里「研究员、写手、审校、编辑」四个 Agent 接力写文章，酷炫得很。但落地时第一感受往往是：人多了，幻觉也多了。每个 Agent 都可能在编，上一个编的东西被下一个当真，几轮交接下来，错误像滚雪球。多智能体协作的价值不是「让 AI 像团队一样干活」，而是把一个模糊任务按能力切分，让每个角色只干自己擅长的那一段。切不好，就是五个模型互相复述。 CrewAI 的正确切法 CrewAI 的核心抽象是三样东西：Agent（带 role、goal、backstory）、Task（带 description、expected_output）、Crew（定义流程顺序）。最小可用结构不是五人团，而是两人团：一个执行 Agent 干活，一个审校 Agent 挑错，流程用 sequential 模式串起来。 设计项 常见错误 正确做法 角色数量 一上来 5 个角色 先 2 个，验证再加 expected_output 不写，让模型自由发挥 写清格式、字数、必含字段 流程 全开 hierarchical 顺序 sequential，减少协调开销 工具 每个 Agent 挂一堆 只挂当前任务必需的 1-2 个 三个踩坑实录 第一，死循环与互相甩锅：两个 Agent 都带「再检查一遍」的倾向，会互相把球踢回去直到撞 max_iter。解法是给每个 Task 设明确的 max_iter（CrewAI 里默认 20，建议生产压到 5-8），并在 expected_output 里写死「输出即终止」。第二，交接信息丢失：上一个 Agent 的长输出被截断喂给下一个，关键结论丢了。解法是在 Task 之间要求结构化中间产物（JSON、清单），而不是自由文本。第三，成本爆炸：多 Agent 每多一环就多一轮完整 LLM 调用，一篇文章五人团可能烧掉单 Agent 五倍的 token。先用单 Agent 跑通，确认单 Agent 真的搞不定，再拆角色——这是省钱的铁律。 ...

一个 Agent 干所有事，已经不够用了 9 月中旬，Anthropic 对 Claude Code 做了上线以来最大的一次架构调整：Projects 功能回归，但形态彻底变了。每个项目里不再是一堆零散对话，而是有一个「协调者 Agent」专门负责规划和拆解，把任务分派给多个并行运行的云端子 Agent，每个子 Agent 跑在独立的 git 分支上，干完活再合并。几乎同一时间，Cursor 也上线了测试版 Projects，让一个协调者 Agent 把活分给成千个子 Agent，并能在你合上电脑后继续在云端跑上几个月。 三万个 Agent 是怎么管的 这波转变的底气，来自 Anthropic 自己的内部实践。据披露，他们内部用类似方式管理着约三万个活跃 Agent，并把这套编排技术对外开放。核心难题不是让一个 Agent 写代码，而是让一群 Agent 不打架：协调者要能发现两个子 Agent 改了同一处文件、把冲突标成合并冲突，还要能复用沉淀下来的工作流和子任务模板。这和人类软件团队的分工惊人地相似——有人拆任务，有人写模块，有人管合并，只是把「人」换成了「Agent」。 对工程师意味着什么 短期内，这不是要取代程序员，而是把程序员从「亲手写每一行」里解放出来，去做更值钱的事：定义目标、审查产出、设计验收标准。一个人带一支云端 Agent 小队，并行推进多个功能分支，正在从极客实验变成日常。风险也同步上升：代码重叠、隐性依赖、无人审查的自动合并，都可能让 bug 被批量复制。团队必须配套更严的测试门禁和人工 review 节点。一个朴素的经验是：让 Agent 写代码可以，但「合主干」这一下最好别全自动，至少要有一道人眼把关的闸门。 收束 2026 年的编程 Agent，正式从「副驾驶」进化成「外包团队」。单兵作战的时代结束了，谁先学会当好 Agent 小队的「技术经理」——拆任务、定验收、管合并——谁就能把产能放大一个数量级。 去论坛讨论 关于「编程Agent编队」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

为什么需要编排 单个Agent能做的事有限。复杂任务需要多个Agent分工协作——但协作不是简单地把几个Agent串起来，需要精心设计编排模式。 5种实用编排模式 1. 流水线（Pipeline） 最经典的模式：规划→执行→审查。每个Agent只做一件事，质量最稳定。 2. 主管-工人（Supervisor-Worker） 一个主管Agent拆解任务，分给多个工人Agent执行，主管负责汇总和纠错。适合复杂任务。 3. 辩论（Debate） 多个Agent从不同角度讨论同一个问题，最终达成共识。适合需要多角度分析的决策场景。 4. 层级（Hierarchical） 像公司组织架构一样，顶层战略Agent→中层战术Agent→底层执行Agent。适合大型项目。 5. 动态拓扑（Dynamic） Agent根据任务自动决定和谁协作。最灵活但最难调试，2026年还在早期。 选型建议 简单任务：流水线 中等复杂度：主管-工人 需要深度思考：辩论 不要上来就用动态拓扑，调试会疯

硅基速览 32岁新疆姑娘袁欣创立成都三刻奇想动漫，研发"剧灵绘"多智能体协作系统，实现视频绘制、音频合成全流程自动化。 落户成都高新区天府软件π立方OPC（一人公司）社区，用AI解决传统影视动漫流程割裂、风格一致性难控的痛点。 人民日报2026年5月报道：AI赋能，一人能开公司——OPC社区正在成为AI创业的新物种。 正文 一个人的动漫公司 2026年5月15日，人民日报发表了一篇关于AI赋能创业的报道，其中介绍了32岁的新疆姑娘袁欣和她的"一人动漫公司"。这也是一人公司领域的代表性案例。 袁欣曾在国外学习工程管理，后来发现传统影视动漫制作有两个痛点：流程割裂、风格一致性难控。一个动漫项目需要编剧、分镜、原画、动画、配音、后期等多个环节，每个环节都由不同的人完成，风格很难统一。 于是她创立了成都三刻奇想动漫科技公司，落户成都高新区天府软件π立方OPC（One Person Company，一人公司）社区，研发了一套叫"剧灵绘"的多智能体协作系统。这套系统用多个AI Agent分别承担编剧、分镜、原画、配音等环节，实现视频绘制、音频合成等全流程自动化。 关键是：这家公司只有袁欣一个人。 什么是OPC社区 OPC（One Person Company，一人公司）社区是成都高新区推出的一个新型创业孵化器。它的核心理念是：在AI时代，一个人就可以开一家公司，社区提供办公空间、工商注册、财税代理、融资对接等服务，让一个人就能把公司运营起来。 OPC社区的出现，本身就是AI创业的产物。在没有AI的时代，一个人不可能开一家动漫公司——你至少需要编剧、原画、动画、配音、后期，五六个人才能运转。但在AI时代，这些环节都可以由AI Agent来完成，人只需要做创意决策和质量把控。 成都高新区的OPC社区不是个例。2026年，全国多个城市都在推出类似的"一人公司"扶持政策——杭州、深圳、上海、北京都有类似的AI创业孵化器。 “剧灵绘"的多智能体架构 硅基视角拆解一下"剧灵绘"多智能体协作系统的技术架构： 编剧Agent：根据用户输入的故事概念，自动生成剧本和分镜脚本。 原画Agent：根据分镜脚本，自动生成每个镜头的原画画面。 动画Agent：把原画画面动起来，生成动画片段。 配音Agent：根据剧本自动生成角色配音和旁白。 后期Agent：把动画、配音、音乐合成成最终视频。 每个Agent都专注于一个环节，Agent之间通过共享上下文协作。这就是2026年多智能体系统在创意行业的典型应用——不是一个大模型做所有事，而是多个小模型各司其职、协作完成。 AI动漫的商业机会 袁欣的"剧灵绘"瞄准的市场有多大？ 短视频动漫。 抖音、快手上有大量动漫账号，以前一个人做动漫短视频需要团队，现在用"剧灵绘"一个人就能做。 企业宣传动画。 很多中小企业需要做产品介绍动画，但请动画公司太贵。用AI多智能体系统，成本可以降到十分之一。 教育动画。 教育行业需要大量教学动画，以前做一集动画需要几万到几十万元，用AI可以降到几千元。 这些市场的共同特点：需求量大、单客价不高、需要量产。AI多智能体系统正好适合这种"量产型"需求。 硅基AGI社区在论坛silicon-agi.com上有不少创意行业的从业者在讨论AI多智能体在动漫、广告、影视制作中的应用，从技术架构到商业模式，讨论非常深入。 硅基点评 袁欣的"剧灵绘"一人动漫公司，是2026年AI创业最有代表性的案例之一。它不是"用AI工具做内容”，而是"用AI多智能体系统重构了一个行业的生产流程"。这两者的区别很大——前者是效率提升，后者是范式重构。 硅基视角的判断是：2027-2028年，“AI一人公司"会在创意行业（动漫、广告、设计、写作）率先规模化。因为创意行业的核心资产是"审美和创意”，不是"人力"。AI把生产工具变成了基础设施，真正值钱的是人的创意决策。袁欣一个人做动漫公司，不是因为她比10人团队更强，而是因为她的创意决策+AI的生产执行，效率超过了10人团队。 对创意行业从业者的建议：不要恐慌AI会取代你。要学会"指挥AI团队"——你做创意决策和质量把控，AI Agent做生产执行。这种"一人指挥AI团队"的能力，会成为2027年创意行业最值钱的技能。 延伸阅读 Stability AI寻求出售：Q1亏3000万、欠云厂1亿，开源商业化的死胡同 多智能体协作模式：从层级到对等网络 多智能体编排架构2026：从协作到自治的演进 本文由硅基AGI社区原创，欢迎访问博客 guijiagi.com 获取更多AI实战教程，或到论坛 silicon-agi.com 参与讨论。