工信部发文要求“多智能体协同”了,我连夜重构了团队的Agent架构
上个月团队Review一个RAG项目同事兴冲冲地给我演示一个Agent接了公司知识库能回答各种业务问题。我问他“如果用户问的问题需要查三个不同系统的数据再写一份报告呢”他沉默了。这不是个例。过去半年我见过太多团队拿着一个通用Agent到处试能跑通POC就觉得自己行了。但一到真实业务场景——跨系统、长链路、多步骤——单Agent就原形毕露上下文爆炸、工具调用死循环、任务执行到一半卡住没人救。6月份两份文件让我彻底改变了技术路线5月国家网信办、发改委、工信部联合印发《智能体规范应用与创新发展实施意见》。6月10日工信部又印发了《“人工智能信息通信”创新发展实施意见2026—2028年》。两份文件叠在一起看技术路线图其实很清楚。《智能体规范应用与创新发展实施意见》明确提出要“加强智能体任务理解、任务规划、工具使用、长期记忆、互认互通、群体协同等技术攻关”。同时还说要“研究智能体身份标识、可信互联、合规支付、安全防护、冲突解决等基础技术”。工信部的文件更直接“支持研发专业性高、落地性强的网络大模型和智能体突破大小模型协同、多智能体协同、智能体通信等技术。打造自主智能体通信协议”。翻译成架构师能听懂的话国家不鼓励你堆一个万能大Agent国家要的是多个专业Agent协同工作的体系。 而且这个体系得有标准通信协议——就像当年TCP/IP统一了互联网一样。“多智能体协同”到底长什么样别被“多智能体”这四个字唬住我来拆一下架构。工信部文件里提到的几个技术方向落到架构上大概是这样的大小模型协同。不是所有任务都要上大模型。简单分类、规则判断用小模型跑复杂推理才调大模型。省钱省延迟。多智能体协同。一个Agent负责查库存一个Agent负责算报价一个Agent负责写合同草稿——三个Agent串起来完成一个完整业务流程。关键是怎么让它们不吵架、不抢资源、不互相覆盖数据。智能体通信协议。AIPAgent Interconnection Protocol已经在推了解决的是智能体之间的可信接入、身份认证、能力发现、互联协作这些问题。说白了就是给每个Agent发个“身份证”让它们能互相找到对方、知道对方能干什么、怎么合作。架构怎么改一个实战参考兆企供应链开源的WorkMate框架给了我不少启发。它的架构是“云端集权管控本地轻量执行权限同源映射”。落到代码层面核心逻辑大概是这样的关键不是代码多复杂是控制粒度——每个Agent能访问什么数据、能执行什么操作都得细化到岗位权限级别。不能让一个负责查库存的Agent顺手把财务数据也看了。近期两个技术事件也在印证这个方向6月24日阿里发布了Qwen-AgentWorld一个能模拟七大领域智能体交互环境的语言世界模型。它能模拟文本类MCP、Search、Terminal、SWE和GUI类Web、OS、Android环境。这意味着什么你可以在模拟环境里测试多Agent协同不用在生产环境里“真人试错”。而且35B版本开源了中小团队可以直接拿来用。另一个是OpenClaw社区俗称“龙虾”MIT协议的开源AI执行框架。它能把自然语言指令转化为系统级操作——打开Excel、整理数据、生成图表、发邮件。说白了就是让Agent真的能“动手干活”而不仅仅是“动嘴聊天”。给架构师的三个建议第一别再做“万能Agent”了。政策方向已经很明确——专业分工、协同作战。你的架构得支持多个专业Agent共存而不是一个Agent什么都干。第二提前关注AIP协议。智能体互联协议已经在推了未来智能体之间的通信会有国家标准。现在做架构设计至少得留出协议对接的扩展点别到时候推倒重来。第三控制粒度要细到岗位级别。工信部文件说要“守牢安全底线”。一个Agent能干什么、不能干什么得跟企业权限体系打通。这不是可选项是必选项。讨论问题你们团队现在用的是单Agent架构还是多Agent协同如果要把单Agent拆成多Agent你觉得最大的技术难点在哪——任务拆解、通信协议、还是权限控制评论区聊聊。