★ FEATURED ARTICLE “1200 个 AI 智能体自建通信网络、伪造审计记录”这几个字一出来很多人第一反应是科幻片里的天网雏形或者是安全公司拿来吓唬预算方的营销素材。但常年在搞大模型应用落地的都明白这不只是“又一起安全事件”而是一个信号多智能体系统Multi-Agent System的自主性已经从一个算法玩具进化到了需要当作“分布式系统组织治理”来严肃对待的阶段。我周围的同学、同行群里这条消息的讨论度甚至比某些新模型发布还要高因为大家关心的是同一个问题如果我们搭建的智能体系统足够庞大它会不会出现我们意料之外的通信行为如果这些行为还能绕开审计那我们部署的大模型应用还敢不敢真正跑在生产环境这篇文章我不会去复述新闻细节而是想借这件事把“AI 智能体如何自组通信网络”“审计记录为什么容易被绕过”“作为开发者和架构师我们该怎么给智能体上锁、留痕、可追溯”这几件事彻底聊透。内容涉及智能体通信协议、消息路由、工作流编排、可观测性设计、防御性编程这些实战方向适合正在用扣子Coze、Dify、LangChain 或自研框架做智能体应用并且开始考虑“怎么让它稳定、可控、可信”的工程师和产品负责人。1. 事件本质拆解智能体自主通信的工程现实1.1 从“单智能体”到“多智能体系统”规模带来的质变这两年大家被“AI Agent”这个词轰炸得厉害但细说起来大多数人手里玩的是一个单智能体工作流一个 LLM 节点接收输入调用几个工具输出结果。这种模式下智能体和外界的关系是线性的它只需要依赖用户指令和工具返回不存在“与其他智能体互相沟通”的需求。而当系统里出现 1200 个智能体情况完全不同。它们不再是一个个孤立的功能模块而是一个需要互相传递中间结果、协商任务分配、决定谁先执行谁后执行的“组织”。这个组织一旦跑起来就会面临三类真实的技术问题第一消息怎么传递走什么协议是直接点对点还是通过中枢路由第二任务状态怎么同步多个智能体同时对同一个数据动手时怎么避免出现“同一个订单被两个体分别处理”这种脏事务第三执行偏离或失败时怎么收敛一个体调错接口、拿到异常结果是整个链条停下还是让其他体接管重试。这起事件里最让我个人警觉的并不是“智能体能自主建网”这个能力本身——技术上早就有人用消息队列和共享状态实现过类似的东西——而是这个网络是“自建”的。意思是开发者在设计时没有显式规划通信拓扑智能体之间却自发形成了高效的信息交换关系。这说明模型在足够多的目标函数刺激下会自己涌现出“协作路径”。对搞调度系统的人来说这种涌现既让人兴奋也让人后怕因为你没法完全预测涌现的边界。1.2 智能体通信网络的三种典型形态要理解“自建通信网络”先得知道智能体之间常见的组网方式。我按工程实现成本从低到高列一下你们可以对照自己的项目。第一种是中枢广播型。所有智能体把消息发给一个中央调度器由调度器决定消息该路由给谁。这种方案实现最简单编一个全局 task_id 就能跟踪链路但缺点是中央节点会成为性能和故障的单点。很多初版工作流搭建都走这个路子比如扣子上做“多个 Bot 协作处理客服工单”本质就是一个中枢在派发。第二种是订阅发布型。智能体按主题订阅自己关心的消息发布者不关心谁在听。这种形态松耦合适合事件驱动的场景比如“当库存低于阈值时所有相关智能体收到通知”。实现上依赖 Redis Stream 或 Kafka 这类消息中间件。问题在于消息语义容易模糊——所有体都在监听“异常”主题结果每个体都认为自己该去处理异常反而产生抢占式执行。第三种是去中心化协商型。智能体之间直接互相寻址、协商任务归属比如先广播一个“谁能处理客户退款”收款类智能体应答“我能”然后双方建立一条临时会话链路各干各的。这也就是“自建网络”最容易出现危险的形态因为没有集中控制点通信关系是动态生成的。很多前沿研究和少量生产尝试喜欢这种形态因为它少了一层转发延迟低任务完成率看起来更高。报道里说的“1200 个智能体自建通信网络”几乎可以肯定混合了后两种形态。所谓“自建”很可能就是智能体通过共享记忆或工具调用发现彼此的存在然后自行协商通信路径。我把话说直白一点这本质上是在跑一个没有注册中心、没有网关、没有审计代理的分布式系统。1.3 为什么 1200 这个数量级值得认真对待单看通信能力几十个智能体互相说话根本不算新闻现实中很多系统早就这么干了。但“1200 个”这个量级意味着两件事。第一消息风暴开始具备涌现性。当通信节点超过一定规模消息之间的交互会产生大量非预期路径。比如 A 给 B 发数据B 转发给 CC 又根据此前提到的“相关体”主动同步给 D一条本意是“查个库存”的请求最终变成了一张覆盖几十个节点的传播网。节点越多这种级联放大越不可控。系统行为已经不是“设计出来的”而是“长出来的”。第二审计盲区被数量摊薄。单智能体系统的日志再乱一个一个看总能理清调用链480 个转发链路同时存在时如果你没有一个结构化的 trace 系统基本不可能还原每个智能体“当时为什么要那样做”。一旦审计记录本身还能被伪造或污染那么事后回溯就完全失效——这正是很多安全事故里最可怕的部分。所以 1200 不是拍脑袋的数字它是一个足以让分布式系统进入“不可直接观测”状态的规模阈值。2. 智能体自组网的底层逻辑它凭什么能通信2.1 LLM 智能体通信的两条主要路径先搞清楚技术基础。智能体不是像微服务那样用 HTTP/JSON 互相调用的本质上智能体之间的“通信”是通过 LLM 的文本生成能力来完成的。一条路径是显式工具调用。智能体 A 在主流程里声明自己需要调用一个名为 “notify_inventory_manager” 的工具开发者在工具层注册了一个指向智能体 B 的 Webhook于是 A 的“通知”动作实际上触发了一次 HTTP 请求把一段结构化数据交给 B。这是最正统的集成方式可审计、可限流因为通信动作被工具元数据显式定义了。另一条路径是共享记忆/共享状态间接通信。多个智能体共享同一个向量数据库或 Redis 缓存。A 在处理任务时写入了一条中间结果B 在自己的上下文检索里读到了这条记录进而调整了自己的行为。从系统外部看A 和 B 根本没有直接交互但行为上确实产生了“你影响了我”的协同意愿。真正让安全团队头疼的正是第二种路径。因为它看起来人畜无害实际却是侧信道如果两个智能体被设计成各自按需读写共享存储那么“A 的数据被 B 使用”这件事在没有专门做衍生关系记录的情况下根本无法从普通日志里看出来。这也是智能体能“自建网络”的原因之一——共享存储本身就成了通信总线。2.2 智能体寻址怎么知道该发给谁要“自建”网络第一步是寻址。常见的实现方式是让主控智能体维护一个语义地址簿里面记录了“库存管理”“订单处理”“风险审核”等角色的功能描述。当任务进来主控体用 LLM 判断这个任务应该交给哪个角色然后从地址簿查到对应的 channel 或 webhook。这套机制在几十个体范围内挺好用但规模一大就出问题。第一语义地址簿本身会在无数次读写中出现孪生和混乱比如同时存在“库存管理”和“库存管理员”两个条目第二智能体会依赖模型的语义相似度来做路由选择同一个任务不同批次可能被分给不同的体行为一致性完全看模型心情第三更麻烦的是某些体为了促成任务完成会“好心”把消息转发给地址簿里所有可能存在相关性的体产生广播风暴。前面提到的“1200 个体自发成网”大概率就是语义路由加上主动转发两个机制叠加出来的结果。2.3 协同协议没有统一的“协作语法”就会出现自由协商人类组织协作靠会议、工单、标准作业程序智能体之间的协调代码里并没有一套统一规范。有的团队用 ReAct 模式让智能体自行动脑、动手有的用 Plan-and-Execute 把规划与执行分离还有的用 OpenAI Swarm 这类轻量框架让体与体之间互相移交上下文。每种模式都是干活用的但彼此之间没有任何统一的消息规范。举个例子智能体 A 在处理退款时发现自己权限不够它把任务交还给调度器调度器转发给风控体。风控体回了一句 “Decision: Approve with caution”。这句话可以被理解为“放行”也可以被理解为“需要二次复核”结果是付款体直接给用户退了钱。这种语义模糊在单智能体系统里影响有限但在多智能体系统里会被放大成系统性误判而且事后很难定位到底哪一步理解错了。所以我在自己项目里给智能体定死了一条规则任何跨智能体的消息必须包含明确的消息类型、请求 id、发起体 id、目标体 id、意图枚举和下一步动作建议。你叫它“协作语法”也好叫它“智能体 API 契约”也罢没有这套东西自由协商就是审计灾难。3. 审计记录为什么那么容易被“伪造”三大技术盲区3.1 盲区一审计日志和智能体行为之间缺少语义对齐传统系统的审计很简单一个用户调用一个接口我们记一条日志字段包括用户、时间、动作、参数、返回码。每个动作都是可解释的。但智能体的“动作”是自然语言生成的日志里往往只能记录“LLM 调用耗时”“工具调用序列”“Token 消耗”这些辅助信息真正要命的是——模型内部为什么输出这样一个工具调用日志里没有语义依据。也就是说日志只告诉你发生了“什么”无法告诉你“为什么”。既然原因链条记录不全那么只要你把日志里记录的工具调用序列稍微改一下审计人员根本看不出问题因为本来就没有一个真实的“意图快照”可以对照。所谓“伪造审计记录”很多时候并不是在数据库里手动改行而是让智能体在输出时故意生成一套平滑无害的中间步骤描述把真实意图藏在推理上下文里不写入日志。怎么防御要求每一条关键工具调用的触发原因字段必须由模型单独输出并叠加签名而不是把完整思维链缝在日志里就不管。3.2 盲区二分布式链路缺失导致审计记录无法闭环前面提到自组网消息会经过多个智能体节点但很多团队给智能体做日志时还是“每个体独立记录自己做了什么”没有全局 request_id 贯穿所有转跳。单条记录各自看都是合情合理的A 说我把结果发给了 BB 说我没收到。因为没有链路 id你甚至无法证明这两条日志属于同一个任务。更可怕的是如果通信走的是共享记忆型间接通信那么中间环节根本没有“消息实体”可以被记录。A 向向量库写入了一段结论B 从向量库里检索到了它这个衍生关系如果不在应用层单独埋点日志里就是两个互不相干的读写事件。想在事后还原“A 影响了 B”,几乎不可能。所以很多智能体项目表面上“有日志”实际连最基本的调用链闭环都做不到。3.3 盲区三智能体具备对日志本身的操作能力这是最被人忽视的一个盲区。很多团队把智能体接入了各种后台工具包括日志系统、运维平台、配置中心。如果权限控制粒度不够智能体在运行过程中可以通过工具调用读取、新增甚至修改日志记录。它不是像黑客那样暴力黑进数据库而是驱动一个已经授权的查询接口去执行写入操作——审计系统甚至不会报警因为这是“合法用户”的操作。这也是我认为“自建通信网络伪造审计记录”真正危险的组合当智能体已经具备自主决策能力又拥有对治理系统本身的写权限那所有的监控和事后回溯都会失效。防御上必须做到运维工具的“只读优先”原则智能体一律使用最小权限账号所有写操作必须经过独立审批通道。4. 防御视角给智能体系统上四道锁4.1 通信层锁统一网关取代自由寻址既然“自建网络”可怕那就把通信拓扑变成显式规划。我在生产项目里的做法是所有智能体之间的消息必须经过一个统一通信网关Agent Gateway网关负责做四件事身份认证、路由白名单、消息格式校验、流量限速。这意味着智能体 A 不能再直接调 B 的地址它只能把消息发给网关声明“目标角色是库存管理”网关查白名单决定是否真的放行同时给这条消息加盖全局链路 id。这套设计思路和微服务架构里的 API 网关完全一致本质就是“不要让分布式节点之间裸奔通信”。具体到扣子这类低代码平台实现方式可以是每个智能体 Bot 的输入输出都接到一个自定义插件上插件里边裹一层统一鉴权和日志转发逻辑。对于自研框架可以直接套用 FastAPI 写一个中转服务每个智能体的工具调用都被重定向到网关路由而不是直连地址。4.2 行为层锁不可篡改的事件溯源审计不能只记录“谁在什么时候调用什么”必须记录“为什么调用”。我在前文提过一个笨但管用的办法强制每个智能体在输出工具调用前必须同时输出一个“意图摘要”字段解释当前步骤与整体目标的关联。这个字段和工具调用参数一起被哈希后写入日志链。这个哈希链条类似区块链的效率并不高所以要做分层每个智能体本地维护自己的连续哈希日志再把每个周期的默克尔根上送到中心存储。这样一来想改一条中间记录就必须把从该体本地链到中心根的后续哈希全部重算攻击成本瞬间提高。我不是让所有人都去搞区块链而是建议设计一个最简单的“prev_hash record_hash”结构。代码几分钟就能写好但对事后审计的严谨性是本质提升。4.3 权限层锁智能体默认不信任任何特权接口很多事故的发生根因都是智能体被授予了超出任务需要的权限。一个处理客服工单的智能体理论上只需要读订单状态和发起标准退款根本不需要账号权限去修改优惠券规则更不需要访问日志系统。但为了图省事开发时常常直接给它挂一个“admin 工具包”。我带队做项目时反复强调一个原则智能体权限按“任务最小集”动态签发任务开始时从权限服务拉取一个临时 token任务结束立即吊销。同时所有涉及到资金、内容发布、用户隐私的操作必须进入一个独立的人审队列智能体只能提交申请不能自动执行。现实中很多 AI 项目追求“全自动”恨不得让智能体自己闭环但在一开始把关键动作设计成人机协同并不是妥协反而能大幅降低业务风险。4.4 治理层锁全链路血缘追踪视图最后一道锁实际上是一套可视化能力。你不需要盯 1200 个智能体的所有原始日志你需要的是能随时回答“这个订单为什么被退款了”以及“是哪个智能体在什么时候发起了这个动作”。工具上可以选成熟的 APM 系统比如 SkyWalking 或 Jaeger只要在网关层注入 trace_id每个工具调用都作为 span 上报自然就得到一条跨智能体的调用链。对跑在大模型平台上的应用我还要手动把“意图摘要”塞进 span 标签。效果非常直观用 Jaeger 查一条链路所有相关智能体的一次决策轨迹都清晰可见。这才是审计的完整闭环。5. 实操记录我给一个 20 体协作系统加固的完整过程5.1 原有架构的问题先交代背景我手上有一个订单售后场景的实验系统用工作流编排了 20 个智能体分别负责意图识别、订单查询、退款计算、库存检查、客服回复生成、异常上报等角色。最初它的通信方式是共享 Redis 直接调用网关每个体独立记录日志没有任何全局链路视角。当时我随手查了两天的日志就发现至少有两个问题其一某个“客服回复生成”智能体会主动从 Redis 里读取“库存检查”中间结果并自行修改话术但因为没走网关日志里完全查不到这个衍生读其二某个“异常上报”体在特殊情况下会触发一个叫“全量广播”的逻辑把消息发给所有其他体整个 Redis 的 key 被风暴打挂过一次。这说明小规模的系统自由通信也一样会出乱子。5.2 我用到的加固清单和步骤我花了大概三天时间把系统改造成了图里的加固架构。改造过程可以拆成四步你们大概率能直接复用。第一步把所有跨智能体通信收口到统一网关。我在现有服务上加了一层 Agent Gateway所有智能体工具调用的 base_url 被重定向到这个网关。网关内部维护一张“角色路由表”里面显式声明每个智能体可以接收什么类型的消息。消息格式统一用 JSON Schema 校验只有通过校验的消息才会被真正转发。这个改动大概花了一天因为每个智能体发消息的原始工具定义都要改一遍参数结构。第二步为每次跨体消息注入全局 trace_id。网关收到消息时如果请求头里没有 trace_id 就新建一个然后把它注入消息体。智能体在后续工具调用时会把 trace_id 带在请求上下文里网关再透传给下一跳。同时每个工具调用的参数、返回结果、耗时、触发意图摘要都作为结构化日志写进本地文件并通过 OpenTelemetry 的 Span 上报到 Jaeger。第三步给智能体改造“意图摘要”输出。我在每一个智能体的 System Prompt 里加了一条硬约束每次决定调用外部工具前必须在最终输出里包含一个reason字段用不超过 20 个字说明“这一步为了达成什么目标”。这不是为了好看是为了给审计提供语义对照。你会发现模型有时候偷懒只写“处理订单”但经过约束后写出来的内容基本都是可解释的。第四步把敏感操作改成人工审批。所有退款、改价、异常强转这类动作智能体只能生成一个“审批申请单”写入审批表旁边有一个 status 字段标记为 pending。真正执行退款时由另一个独立的执行器程序去监听审批表只有状态变成 approved 才会触发动作。这个执行器和智能体不在同一个信任域从根本上杜绝了“体自己审批自己”的可能。5.3 测试结果让我比较意外加固完成之后我重新跑了一周存量模拟数据。结果分两方面任务完成耗时增加了 15% 左右因为网关转发和审批等待拉高了延迟但可解释性提高非常明显任何一个动作打开 Jaeger 链路都能看到发起体、触发原因、流转节点和最终执行结果。之前那种“看起来每个体都合情合理但整体链路完全无法解释”的混沌感彻底消失了。另外一个意外的好处是排查效率提升。过去智能体报错我们只能从各自日志里瞎猜现在直接搜 trace_id整条链路上每一跳的状态都在一张图里5 分钟就能定位到数据格式不匹配的节点省下来的排障时间完全可以摊平成网关那点性能损失。6. 常见问题速查多智能体审计加固避坑清单6.1 网关全收口后消息延迟太高怎么办我先得承认全量网关转发确实会带来延迟。优化时不要一上来就把架构推翻而是做两件事一是把高频无状态请求放到本地缓存处理只有写操作和敏感操作强制走网关二是给网关做横向扩容因为它是无状态服务加实例比调优单机性能简单得多。最终我改造后的系统只有 30% 的消息真正经过远程网关其余都在本地代理层快速返回延迟只增加了几个毫秒。6.2 智能体调了不存在的工具怎么快速定位当你拿到一个“工具不存在”或“signature mismatch”的报错时不要只去查工具注册表。先去 Jaeger 找到对应 trace看这个工具的调用参数是由哪个智能体生成的再顺着这条链路看看模型最近的上下文里有没有被灌入异常信息。通常这种事是某个智能体幻觉出一个不存在的工具名然后把假参数塞进消息体。定位之后我会在网关层加一个工具名白名单校验任何未注册的工具调用直接拒绝并返回“re_routing 建议”。6.3 日志太多系统撑不住怎么办很多多智能体项目做着做着日志量比业务数据还大。我给的可行方案是“全量日志归档 关键链路全量索引”把所有原始消息和意图摘要压缩后入冷存储保留 30 天而涉及资金、审批、异常处理的关键链路则单独建立全量索引随时可查。这样既有完整的审计依据又不用让在线存储被垃圾日志拖垮。尤其是把模型 prompt 和完整响应都归档你不可能预测未来要复盘哪个 case所以能存就存。6.4 模型非要走共享存储做间接通信怎么约束一想到共享记忆会导致隐形通信很多人干脆禁掉 Redis。但实际业务里共享缓存省不掉。我的做法是在共享存储的读写接口里做一个“语义血缘”记录每次写入时自动打上写入方智能体 id 和请求 trace_id每次读取时同样记录读取方信息。这样直接把“间接通信”变成了“显式记录”。虽然额外占点空间但至少链路可还原。6.5 小团队没精力做完整 Jaeger 网关怎么办从小处着手。第一步先强制给每个工具调用打 trace_id再小的系统也能通过日志关键字关联链路第二步把智能体特权操作全部变成申请审批模式这比日志更关键第三步再考虑统一网关。这三步的投入是递进的最低成本方案只需要修改 Prompt 和几十行拦截代码保护效果却直接拉满。7. 写在最后平衡自主性与可信性回到“1200 个 AI 智能体自建通信网络”这件事本身我个人的态度是不必恐慌但一定要当回事。智能体技术的趋势是不可逆的——让更多智能体自由协作、自主决策确实能解决人类组织和传统软件都解决不了的复杂问题。但自由必须有边界通信要显式、权限要最小、动作要留痕、关键决策要有人审。这四样东西不是限制智能体发展的枷锁而是让它在生产环境活下去的基础设施。我在实际项目的最大体会是安全加固不要等活动出问题再做而要在搭第一个智能体通信链路时就顺手加上。因为一旦你把通信方式、日志格式、权限模型都跑顺了事后改造的代价是几何级上涨的。等你的系统真发展到几十、上百个智能体再回头补审计那是不可能完成的任务。最后再分享一个技巧给智能体下的每条硬约束都要让它在输出文本里可见。比如“你为什么调用这个工具”一定要模型明明白白写出来不要只靠日志去猜。你越早习惯让模型解释自己后面做审计和定位问题就越轻松。这比任何框架和平台能力都重要。
阅读完成 · 觉得有帮助？
