我在一个企业内部项目里见过一次很典型的多 Agent 事故。团队让三个 Agent 协同生成一份技术选型方案Agent A 负责调研Agent B 负责写章节Agent C 负责审校。半小时后三个 Agent 交出了一份结构完整、语言流畅、看起来非常专业的报告。但读下去就会发现Agent A 把两个不存在的接口写进了调研结果Agent B 不仅没有发现异常还把这两个“编造出来的接口”当成了选型依据Agent C 的审校结论竟然是“内容充分未发现明显问题”。这个场景不是模型不够聪明也不是某个 Agent 能力弱。真正的问题是这三个 Agent 从一开始就没有被放在一个有边界的协作环境里。它们可以自由调用搜索、自由生成结论、自由往下游传结果中间没有沙箱隔离没有技能版本约束也没有任何人工审批点。这就是我想聊的 Harness Engineering。它不是一个新框架的名字也不是某个开源项目而是一组企业级多 Agent 协同项目的工程约束方法。核心就一句话先给 Agent 画好边界再让它在边界里发挥能力。2026 年往后AI Agent 工程化落地的胜负手大概率不在模型评测指标上而在这套约束手段是否齐备。1. 先回答一个问题企业级多 Agent 协同真正缺的是什么1.1 从“三 Agent 事故”说起上面那个调研场景问题出在哪一层出在 Agent 之间的信任被过度放大了。Agent A 输出了一段文本Agent B 就把这些文本当成了事实Agent B 把这段文本当成了输入继续往下游加工Agent C 又基于“生成内容必须保留完整”的假设做了无效审校。这不是模型幻觉问题至少不全是。单 Agent 模型产生幻觉最多是一份内容里出现错误多 Agent 协同产生幻觉会把错误一层一层放大最终在很深的链路里变成一个看起来无比真实的结论。等人工发现时可能已经进入到了下游流程。所以企业级多 Agent 协同真正缺的不是“更强的模型”而是“能在多环节组合之后依然保持可控”的工程机制。你无法保证每个 Agent 每一次都不出错但你可以通过约束和检查让错误不会无限制地向下游传播。1.2 多 Agent 协同的本质是概率系统的组合单个 Agent 的输出本身是概率性的。同一个问题温度参数不同输出就可能不同同一个输入上下文稍微变化结果也会漂移。当多个 Agent 串联或并联在一起时这种不确定性不是简单相加而是会放大。常见的放大路径有几种事实漂移上游 Agent 生成了有偏差的结论下游 Agent 把它当作事实继续推理。上下文污染一个 Agent 的中间输出占用了大量上下文导致另一个 Agent 忽略了关键指令。死循环Agent A 调用 Agent BB 返回一个“需要再确认”的结果A 再调用 B反复空转。越权调用一个 Agent 本来只该读数据库结果因为工具描述写得模糊它去执行了写操作。这些问题的共同点在于它们都发生在“边界”两侧而不是模型内部。模型负责生成内容边界负责决定内容能不能传到下一环节。如果边界缺失模型能力再强组合起来的系统也是脆弱的。1.3 Harness Engineering 的定位先谈边界再谈协同“Harness”这个词的本义是马具、缰绳工程上常用来指“能把动力安全传导出去的约束装置”。在多 Agent 项目里Harness Engineering 可以理解为一套给 Agent 套上约束和护栏的工程实践。这套实践通常包含三层沙箱限制 Agent 能访问的文件、网络、系统调用和资源。自进化 Skill把 Agent 的临时能力沉淀成结构化、可版本管理、可回归测试的技能资产。人工介入在关键流程节点保留人的确认、拒绝、回退和审计能力。听起来这三件事都不新鲜。但在多 Agent 项目里它们不是可选项而是让系统能从“跑得通”变成“用得住”的前提。单 Agent 做一个问答不需要这么重多个 Agent 开始跨模块协作、处理企业真实数据、触发真实操作时没有这三层约束几乎等于在裸奔。2. Harness 三大支柱之一沙箱让 Agent 只能拿到“该拿到的”2.1 沙箱隔离的四个维度企业级 Agent 一定会调用外部资源读文件、访问数据库、调用 API、执行脚本。这些操作如果不受控制就是安全和管理上的黑洞。沙箱的作用不是限制 AI 发挥而是把 Agent 的活动范围限制在“本次任务必须访问的资源”之内。比较关键的隔离维度有四个文件系统Agent 只能读写某个临时目录或挂载目录不能扫描整个服务器。网络Agent 只能访问白名单内的域名或内网地址不能把企业内部数据往外传。系统调用Agent 不能执行未经允许的 shell 命令、不能加载内核模块。资源配额对 CPU、内存、超时时间做上限防止一个失控 Agent 打垮整个服务。实际操作中文件系统隔离最容易出问题也最容易被忽略。很多平台默认情况下只允许 Agent 在沙箱内写临时文件如果需要让它读取某个业务目录必须在配置里显式挂载。这里提供一个实操经验落地时先给 Agent 一个空目录让它跑一次文件读取任务再把读不到的路径逐个加白效果比一开始放开整个文件系统要安全得多。2.2 不同层级的沙箱怎么选沙箱不是一个单一产品而是一系列方案的合称。常见的有四类方案隔离强度配置成本适用场景操作系统容器Docker、gVisor高中运行不确定 CLI、隔离第三方工具Serverless 函数计算中高低无状态函数、弹性请求、按量付费Wasm 沙箱中中插件化 Skill、嵌入宿主进程平台内置沙箱低到中低低代码平台内运行 AI 节点如果你用 Dify、n8n 这类可视化流程平台里面对 AI Agent 节点往往有内置沙箱常见问题是“沙箱里能不能写文件”。先说结论能但需要显式配置。不同版本、不同部署方式差异很大有的要求你在插件配置里声明可写目录有的要求给执行环境挂载持久卷。落地前先去翻官方文档确认你要跑的代码节点到底运行在什么执行器上再决定挂载方式。Wasm 沙箱是另一个值得关注的轻量方案。它的原理是把 Agent 要运行的插件或函数编译成 Wasm 模块宿主只暴露白名单内的导入函数让模块只能调用被允许的 API。这种方案很适合做“Skill 插件”的运行时隔离因为它启动快、内存开销小。但它也有边界Wasm 沙箱不能完全替代操作系统级隔离遇到需要访问 GPU、复杂系统调用的场景还是要回退到容器级方案。如果你在 Linux 环境里遇到“当前环境无法创建沙箱命名空间”这类报错先不要怀疑是代码问题。通常要检查三件事用户是否有创建 namespace 的权限、内核是否开启了相关模块、容器环境是否限制了特权模式。这类问题往往和环境权限有关不是业务代码本身的问题。2.3 沙箱落地的三个坑从我接触过的项目看沙箱最容易在三个地方失效。第一配置太宽。有人为了让 Agent “更自由”直接把临时目录设成根目录、把网络白名单设成*。这样确实不会因为权限报错但 Agent 一旦接到一个恶意或异常输入后果就是整台机器暴露在风险里。更稳妥的做法是默认拒绝、按需放行。第二清理不彻底。每次 Agent 执行完成后沙箱里的临时文件、中间结果、缓存如果没有清理下一次执行就会受到上次结果的污染。尤其是自进化 Skill 场景Agent 会把上一次的“成功经验”写到临时文件里下一次执行时读出来当下文结果越走越偏。建议每次执行都从干净的镜像或基线目录启动执行完统一回收。第三只隔离了文件没隔离网络。很多团队部署沙箱时只关注文件系统忽略了网络出口。Agent 可以通过requests库访问内网未授权接口也可以把数据发到外部域名。对于企业级项目网络白名单往往比文件权限更重要。至少要做到默认不允许 Agent 发起对外网络请求需要时逐条加白并把内网敏感域名排除在外。注意不要因为一次报错就立刻放开沙箱权限。默认拒绝、按需放行是沙箱配置里最值得遵守的规则。3. Harness 三大支柱之二自进化 Skill把不确定能力变成受管资产3.1 Prompt 为什么不能直接当资产多 Agent 协同过程中你会发现同一个任务反复以不同方式做。今天 Agent A 用一条长 Prompt 完成了销售数据汇总明天 Agent B 又用另一条 Prompt 做相似的事。这些 Prompt 分散在各处没有结构、没有版本、没有验证改一个词可能影响全流程。Prompt 是文本不是资产。企业级项目需要的是 Skill——一个具备描述、输入输出定义、执行逻辑、验证用例、版本号、已知失败模式的结构化单元。Skill 的目的是把“某一次跑通”变成“可以反复使用、可以测试、可以回滚”的能力。3.2 自进化 Skill 的三层机制所谓“自进化”不是让 Agent 随意改写自己的技能。真正可落地的自进化 Skill需要做成受控的闭环。第一层运行时采集。在 Agent 执行任务时自动记录成功与失败样本、异常信息、用户的修正行为。注意这里只做记录不做自动改写。第二层人工审核。每隔一段时间把采集到的失败样本和修正反馈汇总由人工判断哪些值得沉淀。比如用户反复把某个输出格式改成表格这就是一个强烈的信号说明 Skill 的输出定义需要调整。第三层回归验证。每次更新 Skill 之前把历史任务和构造的验证用例跑一遍确保新版本没有破坏旧功能。这比单纯让模型“优化”要可靠得多。这就是一个很关键的判断自进化 Skill 的“自”应该体现在“自动提出候选”而不是“自动生效”。企业级场景下很难接受一个技能因为一次偶然反馈就自动改掉自己的行为。比较合理的节奏是Agent 提出候选 → 人工审核 → 回归验证 → 灰度发布。如果某一个环节缺失长期使用一定会出问题。3.3 一个可参考的 Skill 开发模板如果你刚开始做 Skill 库可以先按下面的结构组织。这是一个通用示例不是某个平台的特定格式落地时需要根据你自己的框架做调整。--- name: web_search_summary description: 搜索并总结给定主题 version: 1.2.0 inputs: - name: query type: string required: true description: 搜索关键词 - name: max_results type: integer default: 5 description: 返回前 N 条结果 outputs: - name: summary type: string description: 结构化摘要 use_cases: - 调研、竞品扫描、知识库补全 known_failures: - 对无搜索结果的主题容易编造来源 - 当 query 包含代码片段时可能截断 validation: - case: 搜索并总结某主题 expected: 输出不超过 500 字至少含 3 个来源无编造版本 ---上面的known_failures部分往往被忽略但它的价值非常高。把已知失败模式写进 Skill 元数据会让 Agent 在调用前就意识到边界也可以在运行后触发进一步的验证逻辑。对多 Agent 协同来说这相当于给下游 Agent 一个前置警告“这个 Skill 在无结果时可能编造来源你校验时要注意。”3.4 自进化不是自动部署Skill 也应该有版本管理。最简单的做法是把 Skill 文件放进 Git 仓库每次更新记录 diff。发布时先灰度到一小部分 Agent确认效果之后再全量。这里有一个容易被忽略的细节Skill 更新后正在运行的长任务要不要重新加载很多平台不会自动热更新Agent 可能还会继续使用旧版本。所以最好在日志里记录每个 Agent 实际使用的 Skill 版本号否则排查问题时会找不到根因。自进化 Skill 的“自”应该体现在自动提出候选而不是自动生效。4. Harness 三大支柱之三人工介入不是干预而是生产流程的闸门4.1 为什么人工介入必须有而不是可选有人觉得把人工介入放在 AI 流程里等于“回归传统软件”说明 AI 能力不够。这个判断是错的。人工介入不是 AI 的补丁而是生产系统的安全闸门。理由很简单多 Agent 系统的错误很难被完全预测。你无法穷举所有输入组合也无法保证模型参数未来不漂移。人工介入的价值在于它把“谁能最终表态”这个问题留给人来判断。尤其是涉及企业数据、客户结果、外部操作时人工确认本质上是一种审计责任划分。4.2 四种人工介入模式不同环节、不同风险等级适合不同的人工介入方式。模式粒度适用场景示例前置审批任务开始前高风险操作删除数据、发送外部消息、购买云资源异常中断流程运行中检测到异常重试超阈值、置信度低、输出格式不符最终确认结果返回前面向用户交付生成报告、发布代码、回复客户事后审计流程结束后常态化监管一周一次抽样复核、全量日志保留实际项目中不要试图每个环节都人工确认。那样会让人变成“按钮点击器”失去真正的监督意义。比较好的做法是低风险、高频的任务自动跑高风险、低频率的操作强制人工同时保留事后审计能力。4.3 设计人工介入的四个原则第一按风险分级。内部文档摘要、字段提取这类任务可以无人化删除、支付、对外发布这些操作必须有人工闸门。判断依据不是“AI 能不能做”而是“做错之后的代价有多大”。第二设超时机制。如果人工长时间不确认Agent 应该挂起或回退而不是继续往下走。否则一个“等人确认”的流程会阻塞整个链路。超时时间一般要结合任务紧急程度和层级角色来定。第三给人工足够上下文。人工审核时只看到一个“请确认”按钮没有意义。要把原始输入、Agent 执行链、工具调用记录、候选输出尽可能地展示出来。人不可能在信息不足时做出好判断。第四可回退。人工驳回后系统要能回到上一个稳定状态。这条意味着 Agent 的执行过程不可变每个步骤都要有日志和快照至少要能恢复到“进入该环节之前”的状态。5. 从 demo 到企业级一条多 Agent 协同项目的落地路径5.1 第一步先跑通单 Agent并记录失败模式很多团队拿到多 Agent 框架后第一件事就是搭好几个 Agent 让它们互相调用。这个顺序是错的。多 Agent 扩大的不只是能力还有故障面。如果单 Agent 都没跑稳多 Agent 出问题时你很难判断到底该修哪一环。合理的第一步是先跑通一个单 Agent处理你真正关心的核心任务同时记录它在各种输入下的失败模式。比如哪些输入会让它编造内容哪些工具调用会超时它当前的响应延迟和 token 成本是多少这些记录会直接成为后续沙箱规则和 Skill 验证用例的输入。5.2 第二步用“2-3 个 Agent 人工收口”做窄协同单 Agent 稳定之后再考虑两到三个 Agent 的窄协同。这里的建议是链条不要太长最好控制在三跳以内关键环节一定要有人工确认。窄协同的典型结构是一个 Agent 负责输入解析和流程调度一个 Agent 负责领域处理再有一个 Agent 负责结果校验。下游的校验 Agent 不能只做“看起来是否合理”的模糊检查它需要有明确的校验规则比如字段是否缺失、数字是否异常、来源是否存在。在这里人工收口不是“每个 Agent 输出都让人看一眼”而是在每个业务边界上设一个确认点。比如“生成对外方案”之前一定让业务负责人确认一次。这样既保留了协同效率又避免了错误自动流向下游。5.3 第三步加上沙箱、Skill 库、观测和灰度窄协同跑顺之后再逐步补齐工程能力。这一步不建议一上来就用复杂的自研平台可以先基于成熟的低代码编排工具把流程串起来。n8n、Dify 这类工具里都有 AI Agent 节点它们能让你快速搭出包含分支、重试、人工确认的流程。等流程验证稳定了再决定是否需要自研。在放量之前可以按这份清单检查一遍[ ] 每个 Agent 的输入输出 schema 是否已经定义清楚[ ] 所有外部调用是否已经放进沙箱并按最小权限放行[ ] 关键 Skill 是否有验证用例是否做了版本管理[ ] 人工确认的超时、驳回、回退逻辑是否已经配置[ ] 日志、trace、token 成本指标是否已经接入[ ] 是否具备一键回滚到上一个稳定版本的能力这份清单本质上是“Harness Engineering 的体检表”。它不是流程负担而是把一个多 Agent 系统从“实验室状态”变成“生产状态”的最小工程集。5.4 小团队不要一开始就自研编排平台我见过不少小团队因为觉得低代码平台不够“酷”从第一天就开始搭自己的 Agent 编排平台结果半年后还在修基础功能业务场景没有任何产出。比较务实的路径是先借用成熟工具的编排能力和沙箱能力把流程跑通当业务量、并发、定制化需求真的压过现有工具的能力边界时再考虑自研。自研的启动时机应该是“现有工具成为瓶颈”而不是“觉得它不够酷”。6. 出了问题怎么排查从现象到根因的检查顺序6.1 先判断现象属于哪一类多 Agent 项目出问题表面现象往往相似但根因层级不同。先不要急着改代码按现象分类现象常见根因层级死循环 / 互相调用编排层越权访问、读取到不该读的文件沙箱配置层结果每次都不一样参数层 / 输入层突然跳过人工确认治理层沙箱报错、权限不足环境层6.2 按五层顺序排查我的建议是遵循输入层 → 环境层 → 参数层 → 编排层 → 治理层。先说输入层。看两个 Agent 之间传的消息是否符合预期。最常见的问题是上游 Agent 返回的不是结构化的 JSON而是解释性文字下游解析失败。也常见上游把空字符串、空数组当成有效结果传给下游下游又基于“返回值不能为空”的错误假设继续处理。这一步不要相信日志里的正常返回要落到具体字段上。然后是环境层。确认 Agent 执行时用的沙箱权限、依赖版本、网络白名单是否和预期一致。比如之前能写文件部署到新环境后突然不能写往往不是代码改了而是新环境没有挂载目录。遇到“无法创建沙箱命名空间”这类报错先检查容器权限和内核模块。接着是参数层。检查模型的温度、top_p、最大 token、重试次数、并行度。多 Agent 协同中重试次数最容易翻车。一个 Agent 调用失败自动重试 5 次每次消耗大量 token还可能导致下游在等待期间重复触发。建议对每个 Agent 单独配置重试策略而不是全局统一。再到编排层。检查 Agent 之间的调用关系有没有形成环有没有 A 等 B、B 等 A 的死锁。也检查一下是否有“Agent 给自己发消息”的情况。很多框架支持消息订阅但配置错误时可能把消息发给所有人导致重复消费。最后是治理层。查 Skill 版本是否发生变化人工确认策略是否被覆盖审计日志是否保留。有时问题不是某次执行坏了而是某个 Skill 在无人知情的状态下被更新导致行为漂移。这项检查需要依赖前面提到的版本记录。6.3 把一次排查沉淀成防复发资产找到根因后不要只修代码。把失败样本、根因、修复方式整理到 Skill 的失败模式或验证用例里再跑一遍回归。这样每一次事故都在为系统增加一层防护。长期下来系统的可控性会逐渐增强而不是继续依赖“本次运气好”。排查多 Agent 问题先看输入再看环境最后才怀疑模型能力。大部分所谓“模型变笨”的故障其实出在链路和权限上。7. Harness Engineering 适合谁不适合谁7.1 更适合的场景这套方法更适合以下情况团队已经跑通了单 Agent 或简单自动化流程现在想把多个 Agent 组成一条生产链路。业务对可控性、可审计性有明确要求比如对外输出、数据操作、流程审批。团队希望把 Agent 能力变成可沉淀的资产