多 Agent 协同这几年从演示走向工程落地最大的变化不是模型能力又提升了多少而是大家终于开始把 AI Agent 当成一个子系统来设计它怎么被触发、怎么调用工具、怎么写入结果、出错了谁来兜底。像 Harness Engineering 这类概念本质上就是在回答一个问题——企业级项目里多个 AI Agent 一起工作靠什么保证整体可控。这篇文章我会按落地顺序拆开讲多 Agent 编排、沙箱隔离、自进化 Skill、人工介入以及从零到生产环境的六个阶段。适合已经在做 AI Agent 开发、准备把协作型 Agent 放到真实业务里的人如果你还在跑单 Agent Demo也可以先看后两章避免一上来就堆配置。1. 多 Agent 协同不是“多开几个角色”而是链路控制问题很多人理解多 Agent 就是“规划者、执行者、审核者各一个然后让它们互相发消息”。这种理解不能说错但离工程化还很远。多 Agent 系统容易跑 Demo难在稳定、可观测、可控地跑生产任务。我见过不少团队把多个角色 Agent 串起来后效果反而不如单 Agent。原因不是模型变笨了而是链路中每一步都会引入新的不确定性消息丢字段、上下文超长被截断、前一个 Agent 的幻觉被后一个当成了事实。这些都不是模型能力问题是链路控制问题。1.1 先分清编排模式串行、分层、计划-执行、辩论不同协同模式适合不同任务先把模式选对再谈参数和优化。编排模式适合场景主要风险串行流水线固定流程如“抽取-清洗-生成-校验”前一步错误向后传递错误被放大分层主管-执行任务拆解后下发给多个执行 Agent拆解粒度不均上下文传递容易丢失计划-执行先规划再执行计划与执行解耦计划与实际脱节执行阶段需要纠偏多角色辩论/评审对结果做多视角校核token 成本高容易陷入重复循环生产环境里基本不会只用一种模式。常见做法是外层用计划-执行内层用串行流水线关键节点再加一个评审角色。重点不是选“最好的模式”而是确认每一步的输入输出是有明确边界的。1.2 协同链路上最常见的四个故障点多 Agent 崩掉通常不是程序崩溃而是链路悄无声息地劣化。状态丢失Agent A 生成中间结果后Agent B 拿到的是截断或重写后的内容关键字段被丢掉。错误放大B 把 A 的结论当成事实继续推导A 的一个幻觉变成最终报告的立论基础。责任不清输出错了但 trace 里看不到是哪一步埋的雷修复和追责都困难。权限越界某个执行 Agent 拿到了超出任务的权限比如一个只做文本总结的 Agent 被配置了写数据库的能力。这四个故障点有一个共同特征只有在运行过程中才会暴露静态 review 很难发现。所以多 Agent 系统从一开始就要把日志、链路 ID、消息协议设计好否则后面排错会非常痛苦。1.3 好的协同系统有什么特征好的协同系统不需要每一步都聪明但必须可观测、可重放、可回滚、可限流。可观测是每一步的输入输出、token 消耗、工具调用参数都要留痕。可重放是拿同一份输入能重新跑一遍对比差异。可回滚是发布新 prompt 或新 Skill 后效果变差能退回到旧版本。可限流是防止某个子任务疯狂调用工具把成本打爆。这些要求听着基础实际落地时你会发现很多项目卡在第一步连完整的链路日志都没有。没有日志后面所有优化都没有依据。2. Harness Engineering 到底在解决什么问题Harness 直译是挽具、控制装置。在 AI Agent 场景里它指围绕模型构建的那层控制结构。你的提示词、工具列表、记忆策略、输出格式、权限边界、重试逻辑、人工审批规则加在一起就是 harness。与其说它是一项新技术不如说是一套工程实践。我理解 Harness Engineering 的核心问题只有一个如何在模型输出充满不确定性的前提下构建出一个可预测、可交付的系统。模型是变量harness 是让变量收敛的那层壳。2.1 从 Prompt 调试到 Harness 设计关注点变了只调 Prompt 的阶段关注的是“这句指令能不能让模型产出想要的文本”。到了工程化阶段关注点变成更多外部约束输出是否符合 schema、工具调用是否被校验、失败任务是否自动重试、敏感操作是否有人工审批、任务跑挂了能不能定位。这是两种完全不同的工作方式。前者是调模型后者是设计系统。很多团队卡住就是因为还在用调 Prompt 的思路做企业级项目结果模型能力不差系统却处处失守。2.2 收敛不确定性的六个抓手我在设计 Agent harness 时一般先检查这六项输出 schema 强制校验规定 Agent 返回 JSON 结构字段类型、必填项、枚举值都要校验。工具白名单和参数校验Agent 只能调用白名单工具工具入参必须按预定义 schema 检查。上下文衰减和摘要超过长度阈值时先摘要再传递防止有效信息被淹没。重试与幂等同一个任务重跑多次不会产生重复外部副作用。评估集回归任何 prompt、Skill、参数改动先在固定评估集上跑一遍。版本化管理prompt、Skill、工具定义都要有版本号能回溯能回滚。这六项不一定要一次全上但迟早都要上。尤其评估集很多团队等到生产事故才补代价太大。2.3 Harness 层要输出什么才叫可交付可交付意味着每次运行都有 trace ID每个 Agent 动作都有审计日志每次输出都有 schema 校验结果每次失败都有重试记录和人工接管入口。这些信息不仅用于排查也用于回答“这个系统到底能不能信任”。如果一次 Agent 任务运行完你只能看到“成功了”或“失败了”这两个词那这个系统还处于玩具阶段。做企业级多 Agent至少要能回答谁调用了哪个工具、输入是什么、输出是什么、花了多少 token、哪一步花了最长时间、为什么失败。3. 沙箱不是可选功能是 Agent 的“最小操作边界”Agent 执行代码、跑脚本、读写文件、调外部接口的时候需要一个受控环境。没有沙箱Agent 的能力越强风险越大。企业级项目里沙箱不是安全团队的额外要求而是 Agent 能获得执行权限的前提条件。我看到很多人讨论“沙箱 wasm 实现原理”“linux 实现沙箱效果”“鸿蒙沙箱”说明大家已经意识到沙箱不是 Docker 一个选项而是一类隔离技术。关键是要想清楚你要隔离什么以及允许 Agent 在隔离区里做什么。3.1 Agent 需要在沙箱里做什么、不能做什么先列能做的运行用户提交的代码片段、执行数据分析脚本、在临时目录生成文件、调用白名单内的内部服务接口、做网络请求但只能访问指定域名。再列不能做的直接访问生产数据库、读取任意磁盘路径、向任意地址发起写请求、无限外网访问、长期占用大量 CPU 和内存、留下未被清理的临时文件。沙箱要限制的不只是网络还包括 CPU 时长、内存上限、磁盘配额、单次执行超时时间。有些任务看着是小问题实际是 Agent 在沙箱里跑了死循环把整台机器拖垮。超时和配额是必须有的。3.2 沙箱实现路线容器、WASM、系统级隔离选哪种沙箱没有标准答案取决于任务特征和现有基础设施。方案隔离强度启动速度适用场景容器Docker/Podman较强秒级复杂代码执行、依赖较重、需要与现有部署体系一致WASM 运行时中等毫秒级高频小任务、纯计算、代码来源不可信但功能有限系统级隔离namespace、seccomp、gVisor较强毫秒到秒级需要兼容普通二进制又不想起完整容器如果你做的是 AI coding 类工具需要跑用户代码容器通常是起步最简单的选择。如果你做的是高频工具调用比如 Agent 反复执行小脚本做数据转换WASM 的冷启动优势很明显。系统级隔离适合对性能敏感、又需要执行普通二进制的场景但对内核参数和运维能力有要求。3.3 沙箱常见的输入输出坑社区里关于“Dify 沙箱环境如何写入文件”“沙箱无法创建命名空间”这类问题很多实际排查下来大部分不是沙箱本身的问题而是输入输出边界没设计清楚。最常见的一个坑是Agent 在沙箱里生成了文件但主进程拿到的路径对不上。原因是沙箱内的工作目录和宿主机挂载路径不是同一套Agent 写的是/workspace/output.csv程序读的是宿主机/data/output.csv。排查时先确认工作目录、挂载路径、输出路径是不是同一个映射。其次是清理问题。沙箱里生成的临时文件如果不清理跑几百个任务后磁盘就满了。我在做批量任务时会在每次任务结束后强制清理临时目录并把清理结果写进日志。再有一个坑是网络边界过于宽松。很多沙箱默认允许外网访问Agent 一旦下载了外部内容谁也无法保证内容安全。建议默认关闭外网需要访问哪些域名用白名单逐个放开。3.4 沙箱和权限的关系沙箱只解决运行隔离不解决授权问题。Agent 在沙箱里能读什么、能写什么、能调用哪些工具、调用前是否需要审批都要单独设计权限模型。建议遵循最小权限原则默认拒绝只有显式分配的能力才开放。比如一个做文本摘要的 Agent不需要写文件能力就只给它读输入、返回文本的权限。另一个做数据清洗的 Agent可以写临时目录但不能访问生产配置。这个边界要在系统设计时就定死不要指望模型自己去判断“该不该执行”。模型没有这种判断能力它只会按指令和工具描述走。4. 自进化 Skill让经验沉淀变成受控流程自进化 Skill 是很多团队最感兴趣、也最容易做偏的部分。理想状态是 Agent 用久了自动积累出一批高质量技能越用越顺手。现实是如果控制不好Skill 库会变成一堆没人说得清效果的 prompt 碎片越进化越乱。关键是把“进化”从模型自动改提示词变成一套受控的工程流程。4.1 Skill 不是“存一段 Prompt”是有验收标准的工程单元一个可管理的 Skill 至少应该包含这些字段name: weekly_report_generator description: 根据项目周报原始数据生成结构化周报 trigger: 输入包含项目进度列表和风险列表 steps: - 解析输入 JSON - 按模板生成周报正文 - 输出 Markdown 文件 tools: - json_parser - markdown_writer input_schema: projects: array risks: array output_schema: report: string validation: - 包含本周完成项 - 风险事项全部在列 version: 1.0.0 owner: ops-team没有这些字段Skill 就只是一段文本无法被版本管理也无法被评估。我建议从第一天就给 Skill 定义版本、负责人、验证标准三个必填项。4.2 什么样的任务值得沉淀成 Skill至少满足三个条件任务可重复一周出现多次而不是一次性需求。结果有明确好坏边界能判断输出对不对而不是“看着还行”。执行过程可被日志还原出问题能回放知道是哪一步造成的。反例是那种“帮我写一段营销文案”的任务。文案好坏没有严格边界每次需求还都不同沉淀成 Skill 后很难验证最终只能变成一堆没人用的模板。4.3 自进化循环采集、候选、验证、评审、发布自进化不是让 Agent 改了某段 Prompt 就直接上线。我一般会走五步采集从运行日志里找出高频任务、成功案例、失败案例。候选根据采集结果生成或修改 Skill 草稿。验证在固定评估集上跑回归对比改动前后成功率。评审人工查看差异确认没有引入副作用。发布灰度上线监控一段时间的成功率再全面放开。这套循环里有模型生成的部分也有人工把关的部分但真正的“进化”发生在验证和评审环节。没有评估集的自进化就是让模型拍脑袋改自己不可控。4.4 防止 Skill 库“越进化越乱”Skill 库的治理比创作更重要。我见过一个团队三个月沉淀了 200 多个 Skill其中一半互相冲突引用关系混乱到没人敢删。后来只能推倒重建。建议提前做好四件事目录规范按业务领域、任务类型、依赖工具分类。版本锁定Agent 运行时绑定 Skill 版本不允许动态引用最新版。引用检查Skill 之间的依赖关系要可视化删除前确认影响面。淘汰机制连续多轮评估集没有提升的 Skill进入待下架池。Skill 库和代码库一样需要持续重构。定期清理比不停新增更重要。5. 人工介入企业级系统里最值钱的一个环节很多人觉得做了多 Agent 就希望全自动人工介入像是系统不够聪明的表现。实际相反企业级系统里人工介入是最重要的质量闸门之一。尤其是写操作、外部调用、代码合并、敏感数据读取这类动作放人工审批不是不信任模型而是对结果负责。5.1 人工介入不是兜底是质量闸门自动化的前提是结果可预期。当任务涉及高风险操作比如对外发消息、写入生产数据库、合并代码、支付相关动作结果一旦错误代价远大于人工审核的成本。这种情况下人工介入是质量闸门不是兜底。判断依据很简单这个操作是否容易回滚如果不可回滚或回滚代价极高就必须有人工介入。5.2 介入点怎么选介入点选在哪里取决于风险、成本和可逆性。操作类型是否自动执行介入建议生成草稿/建议自动无需审批直接输出内部低风险写入临时目录、测试库自动事后审计生产数据写入人工审批需展示完整上下文对外发送消息人工审批需展示内容、接收方、发送时间代码合并人工评审需展示 diff 和测试结果删除操作人工审批默认禁止自动执行低风险且结果有明确验收标准的环节可以自动。高风险、难回滚、结果模糊的环节保留人工。不要一刀切全自动也不建议处处审批否则人工介入队列会爆掉。5.3 人工审核需要看到什么信息如果人工审核只能看到“Agent 请求执行某个操作是否批准”那这个审批就是走过场。审核人需要完整上下文原始输入、Agent 计划、工具调用链、最终输出、diff、token 消耗、模型和 Skill 版本。没有这些信息人工介入反而制造新风险。审核人无法判断操作是否合理只能凭感觉点同意。结果就是审批环节形同虚设。5.4 介入频率和自动化演进人工介入比例不是越低越好而是在评估集稳定、错误影响可控的前提下逐步降低。比如某个审批点连续几百次通过率 99%且错误案例没有造成实质影响才可以把审批放宽为事后审计。这个过程要逐步放。不要因为“看起来稳定”就一次性放开。每放开一个介入点都要保留一段时间的监控和随时切回审批的能力。6. 从零到企业级落地的六个阶段很多项目失败不是因为技术选型不对而是阶段跳跃过大。直接从单 Agent 跳到“多 Agent 自进化 Skill 人工介入”全部铺开一旦出问题根本不知道是哪个环节造成的。我建议把落地拆成六个阶段每个阶段都有明确验收标准过了再进下一步。6.1 阶段划分和每一步的验收标准阶段核心任务验收标准参考阶段一单 Agent 最小闭环50 条真实样例稳定跑通日志完整阶段二结构化输出 评估集输出 schema 校验通过率稳定提升阶段三多 Agent 编排 trace死循环能被检测和终止链路可回放阶段四沙箱 权限 审批越权尝试被拦截审批记录完整阶段五Skill 库 版本化新 Skill 不降低旧用例成功率阶段六生产监控 灰度 回滚故障能快速定位并回滚原始项目标题里提到的“沙箱、自进化 Skill、人工介入”正好对应阶段四和阶段五。它们不是并行铺开的而是有先后顺序。6.2 最小可运行闭环怎么搭建议先选一个高频、低风险、边界清晰的业务比如“把工单内容自动归档并生成摘要”。先做单 Agent带一个工具、一个输出 schema、一份日志跑通后复盘问题再进入下一阶段。这个最小闭环不需要多 Agent不需要 Skill甚至不需要复杂沙箱。它的目标是让团队先建立“输入-处理-输出-日志-评估”的基本习惯。6.3 多 Agent 编排、沙箱、Skill 的先后顺序先编排还是先沙箱我一般先沙箱。因为沙箱直接决定 Agent 能碰什么会提前暴露权限、网络、路径这些基础问题。多 Agent 编排放到沙箱之后可以避免 Agent 在执行任务时绕过边界。Skill 放最后。它依赖稳定的编排和评估集否则连“变好还是变差”都判断不了。很多团队急于做自进化跳过评估集直接让 Agent 改自己结果就是把系统改乱了还不知道是哪次改动导致的。6.4 资源、日志、指标怎么设计从阶段一开始就要把指标定好。我常用的几类任务成功率成功完成任务数 / 总任务数。平均耗时单任务从触发到完成的时间。token 成本总 token、单任务 token按任务类型拆分。重试次数失败后自动重试的次数和原因。人工介入率高频审批点应逐步降低。沙箱拦截率越权、非法路径、超时被拦截的次数。Skill 回退率Skill 发布后被回滚的比例。日志方面每一条运行记录至少包含trace ID、Agent ID、模型版本、prompt 版本、Skill 版本、工具调用参数、输出校验结果、耗时和 token。这些字段在排查时能省大量时间。7. 一套实战排查清单最后整理一份排查清单。这些都是我在实际项目里反复遇到的问题按“先看现象再看输入再看环境再看参数”的顺序走能少走很多弯路。7.1 Agent 卡住或死循环先看最大迭代次数和任务间依赖确认是否有终止条件再查消息协议里是否缺少“结束”标志最后看是不是某个工具被反复调用写了同样的结果。死循环多数不是模型问题是编排逻辑没有收敛条件。7.2 沙箱写入失败按顺序查路径映射、工作目录、挂载权限、磁盘空间、超时时间、文件编码。很多写入失败其实是路径对不上Agent 写到沙箱内目录而程序读的是宿主目录。7.3 Skill 不生效或效果变差先确认 Skill 是否被命中有可能是触发条件写得太严根本没进入执行流程再确认版本和评估集是否对应最后检查是不是评估数据被污染比如测试集里混入了 Skill 训练时的样本。7.4 多 Agent 结果不一致先用固定输入重放排除随机性再检查输入顺序、文件路径、上下文摘要是否一致最后看缓存目录是否被多个 Agent 共同写入导致互相覆盖。多 Agent 共享状态一定要设计好读写锁和命名规则。7.5 人工介入队列堆积先分析是哪个介入点堆积再给审核人提供浓缩上下文把重复审批做成批量处理。如果频繁审批的都是同一类低风险操作说明这个介入点可以降级为事后审计。但降级前必须有足够的历史数据和错误率支撑不要凭感觉放开。多 Agent 工程化落地真正该盯住的不是功能列表而是输入格式、资源边界、失败重试和人工介入这几个基础环节。把单 Agent 跑稳把沙箱边界守住把 Skill 放进受控流程把人工审批做成有数据的决策整个系统才能从“能跑”变成“能交付”。