企业级多Agent协同与Harness Engineering：从可控沙箱到Skill自进化的落地实践

先分享一个最近的落地感受单聊 AI Agent 的时候大家都觉得不难但当我把 Agent 真正放进企业级项目里让它和现有代码库、CI/CD 流程、权限体系、安全基线协作时才发现最难的从来不是“让模型说话”而是“如何让模型在可控的轨道上完成一连串复杂任务”。模型本身再强没有工程化的约束、隔离、评价和介入机制很容易在关键流程里一路跑偏。这也是 Harness Engineering 在 2026 年的 AI 工程化讨论中被反复提及的原因。本文用一套企业级多 Agent 协同项目作为主线逐步拆解其中的关键设计覆盖多 Agent 协作模式、沙箱隔离、Skill 定义与自进化、人工介入时机和完整工程落地。内容偏实战新手可以看概念有基础的开发者可以直接跳到代码和配置部分。1. 从“一个 Agent”到“多个 Agent”到底发生了什么1.1 单 Agent 的能力边界在讨论多 Agent 之前先把单 Agent 的边界说清楚。单 Agent 的输入是用户任务输出是模型直接生成的结果。它适合回答、总结、写代码片段、单文件修改等“窄任务”。一旦任务本身需要跨模块、跨服务、多轮验证单 Agent 就会暴露几个明显问题上下文窗口有限任务链条太长时早期信息被后续内容稀释。模型“身兼数职”既要规划又要执行又要检查容易出现自我纠错能力下降。工具调用缺乏隔离Agent 拿到权限后可能在一个错误分支上持续操作。没有独立的“验证者”视角Agent 自己生成的内容往往很难自己发现漏洞。当然很多项目用单 Agent 大量 Prompt 也能跑通但“能跑通”和“能在企业级生产环境里稳定复用”是两码事。企业对可控性的要求远远高于对单次生成效果的追求。1.2 多 Agent 协作的本质多 Agent 协同项目不是简单地把多个模型实例堆在一起而是通过架构方式把“复杂任务”拆成多个“相对明确的子任务”每个子任务由特定角色负责。这么做的本质是两点降低单个 Agent 的认知负载每个 Agent 只需要关注自己负责的那一段。引入多视角校验机制比如执行 Agent 负责写代码验证 Agent 负责评审安全 Agent 负责基线检查。这里要区分两种常见多 Agent 组织形式组织方式特点适用场景编排式中心化 Orchestrator 负责任务分解与调度其他 Agent 执行子任务流程固定、角色明确企业级项目最常用协作式多个 Agent 相对平等通过共享消息池或工作区协作开放式探索、研究型任务但结果可控性较弱在企业级 AI Coding 场景里目前主流采用编排式结构。整个过程与“项目经理 开发 测试 安全”的软件工程团队很像只是这些角色都换成了 Agent。2. Harness Engineering把 Agent 放入“轨道”2.1 为什么需要 Harness Engineering“Harness”这个词在中文里常被翻译成“挽具”或者“控制装置”。Harness Engineering 的核心理念是不要盲目追求 Agent 的自由度而是通过一套工程化的约束机制把 Agent 的行为引导到可控轨道上。举个例子。直接给 Agent 一个任务“优化用户登录模块”它可能直接修改认证逻辑甚至把 Session 管理也重构了。但如果你给 Agent 一套 Harness它就会知道本次任务只允许修改login相关目录。必须遵守项目现有的代码规范。修改完成后必须跑指定测试用例。涉及数据库表结构变更时只能输出变更脚本不能直接改生产库。无法独立判断时必须标记为“需要人工介入”。这套机制就是 Harness。它不限制模型能力而是定义了模型能力的“使用边界”。2.2 Harness Engineering 包含哪些关键层在企业级环境里Harness Engineering 通常不是单点方案而是多层组合任务边界层明确当前 Agent 能做什么、不能做什么、任务范围是什么。通常通过系统 Prompt、约束文件、权限配置来定义。工具访问层Agent 调用工具前Harness 先做权限检查和参数校验。不是所有模型请求都会直接执行越权工具调用会被拦截。验证与反馈层Agent 完成子任务后Harness 会触发自动验证流程包括编译、单测、静态扫描等并把结果回传给 Agent 进行修改。人工介入层设置关键检查点当任务存在高风险、偏离预期或自动验证失败达到阈值时必须交由人工确认。2.3 从“Prompt Engineering”到“Harness Engineering”理解这两个概念的差异对做工程化决策很有帮助维度Prompt EngineeringHarness Engineering关注点让模型输出更符合预期让模型行为处在可控边界内核心手段Prompt 设计、few-shot、CoT权限、沙箱、校验、人工审批失败模式输出不合理行为越界、误操作、数据泄漏适用阶段模型效果调优生产环境落地Prompt Engineering 依然重要但它是 Harness Engineering 的一个子环节。真正进入企业级落地时光有 Prompt 远远不够。3. 企业级多 Agent 协同架构设计3.1 一个可落地的参考架构下面给出一个适合中小规模企业项目使用的多 Agent 协同架构。架构本身不需要停留在理论层面可以直接映射到实际代码里。整个系统包含以下几类角色Orchestrator Agent编排者接收用户目标拆解任务调度其他 Agent汇总结果。Coder Agent开发负责具体编码、重构、测试用例编写。Reviewer Agent评审负责 Code Review、检查代码风格、指出潜在缺陷。Security Agent安全检查依赖漏洞、硬编码密钥、危险函数调用。Ops Agent运维负责构建验证、部署脚本、环境配置。Human Agent人工在关键决策点介入拥有最终审批权。协作流程可以这样描述Orchestrator 接收高层任务。Orchestrator 将任务拆成影响分析与编码执行两个并行子任务。Coder Agent 在沙箱工作区内修改代码。Reviewer Agent 对 Coder 的产出进行评审并返回修改建议。Security Agent 对代码做安全扫描。所有检查通过后Orchestrator 汇总 Diff 和验证报告。涉及高风险变更时Harness 发起人工审批请求。人工确认后变更进入 CI/CD 流程。3.2 Agent 通信机制消息与工作区多 Agent 之间如何传递信息是整个架构能否稳定运行的关键。目前工程实践中主要用两种方式消息队列模式Agent 之间通过结构化消息通信。每条消息包含事件类型、发送者、接收者、payload、元数据。适合异步解耦。共享工作区模式所有 Agent 操作同一个虚拟工作区通过文件变更来交换信息。适合代码生成场景因为代码评审必须以文件 Diff 为基础。实际项目中两者通常结合使用。多 Agent 系统里也会用到传感器机制即让 Agent 能够感知外部环境的变更例如文件系统变化、测试结果输出、事件消息等。传感器事件会触发 Agent 重新规划工作。下面给出一段 Python 风格的 Agent 消息与事件监听代码用来说明通信模型。# 文件路径agent_core/event_bus.py from dataclasses import dataclass, field from datetime import datetime from enum import Enum from typing import Any, Callable, Dict, List class EventType(Enum): TASK_CREATED task_created CODE_CHANGED code_changed REVIEW_PASSED review_passed REVIEW_REJECTED review_rejected SECURITY_ISSUE security_issue NEEDS_HUMAN needs_human APPROVED approved dataclass class AgentEvent: event_type: EventType source: str target: str all payload: Dict[str, Any] field(default_factorydict) created_at: datetime field(default_factorydatetime.utcnow) class EventBus: 极简事件总线实现用于多 Agent 之间消息解耦。 def __init__(self) - None: self._subscribers: Dict[str, List[Callable[[AgentEvent], None]]] {} def subscribe(self, event_type: EventType, handler: Callable[[AgentEvent], None]) - None: self._subscribers.setdefault(event_type.value, []).append(handler) def publish(self, event: AgentEvent) - None: handlers self._subscribers.get(event.event_type.value, []) for handler in handlers: handler(event)这个代码虽然简单但体现了一个关键设计Agent 之间不直接引用对方对象而是通过事件解耦。这样可以避免因为某个 Agent 升级或失败导致整个协作链路中断。3.3 编排策略流程编排与决策编排多 Agent 的编排策略需要从两个层面考虑。流程编排解决“先做什么后做什么”决策编排解决“出现不同结果时怎么做”。流程编排上企业级项目建议按照“分析 → 编码 → 评审 → 修复 → 安全扫描 → 审批 → 构建”的顺序循环展开。每一步结束后都产生一个事件Orchestrator 根据事件类型决定下一步动作。决策编排上需要给 Orchestrator 定义清晰的路由规则# 文件路径agent_core/router.py def should_request_human_review(code_diff_stats: dict, review_score: int, security_alerts: int) - str: 根据自动化结果决定是否进入人工审批。 # 1. 变更行数过大时强制人工介入 if code_diff_stats.get(total_lines, 0) 500: return human_review # 2. 评审得分低于阈值时重新打回 Coder if review_score 70: return rework # 3. 安全告警超过 1 个时必须人工确认 if security_alerts 1: return human_review # 4. 默认情况走标准审批流程 return standard_approval这里的关键不是逻辑复杂而是要明确自动决策失败时系统有兜底路径。宁可让人多审批一次也不能让 Agent 自己绕过风险。这是企业级 Harness Engineering 的基本原则。4. 沙箱机制给 Agent 一个“可以犯错”的空间4.1 沙箱解决什么问题多 Agent 协同项目中代码生成 Agent 要执行命令、修改文件、运行测试。如果这些操作直接发生在宿主机或真实项目环境一个错误的rm -rf或一个被污染的环境变量可能造成不可逆的破坏。沙箱机制的核心价值是提供一个独立的、受限的、可回收的执行环境。沙箱通常要解决三类问题文件系统隔离Agent 的读写操作只影响沙箱内的目录。进程与资源限制限制 CPU、内存、文件句柄数量避免 Agent 启动失控进程。网络访问控制默认禁止外网访问如果需要访问内部镜像源或 API需要通过白名单代理。4.2 从 Docker 到 WASM 沙箱目前工程中常用的沙箱实现方案包括容器、微虚拟机、WASM 三类沙箱方案隔离粒度启动速度资源占用适用场景Docker 容器进程级中等中等标准代码生成与测试运行Firecracker / gVisor微虚拟机较慢较高高安全场景、多租户隔离WASM 沙箱用户态极快极低策略类 Skill、轻量函数执行WASM 沙箱的实现原理比较值得关注它把代码提前编译成 Wasm 字节码然后在宿主机的 Wasm Runtime 中以受限方式执行不直接访问宿主系统调用接口。这种方式启动快、体积小非常适合运行一些不可信的小工具或策略脚本。4.3 沙箱化 Agent 工作区的最小实现思路下面用一个 Python 子进程示例演示如何在代码执行前设置资源限制和工作目录。# 文件路径sandbox/executor.py import resource import subprocess import tempfile from pathlib import Path class SandboxExecutor: 基于资源限制 独立临时目录的简化沙箱执行器。 def __init__(self, workdir: str None): self.workdir Path(workdir) if workdir else Path(tempfile.mkdtemp(prefixagent_sandbox_)) def run(self, command: list[str], timeout: int 30) - subprocess.CompletedProcess: # 限制 CPU 时间为 10 秒 resource.setrlimit(resource.RLIMIT_CPU, (10, 10)) # 限制子进程最大内存约 512MB resource.setrlimit(resource.RLIMIT_AS, (512 * 1024 * 1024, 512 * 1024 * 1024)) return subprocess.run( command, cwdself.workdir, capture_outputTrue, textTrue, timeouttimeout, checkFalse, )注意这里的 resource 限制只对 Unix 系统有效。实际生产环境如果要达到真正的隔离需要叠加容器或云沙箱服务。这个示例的价值在于说明沙箱的本质不是某个具体工具而是一组约束的组合。4.4 沙箱写入权限的常见坑点有不少项目使用 Dify 或其他平台搭建 Agent 工作流时会遇到“沙箱环境无法写入文件”的问题。这通常不是产品 bug而是设计使然。平台默认沙箱为了安全禁用了持久化写入能力。如果你确认应用场景需要让 Agent 产出文件可以从几个方向排查检查沙箱配置中是否启用了“文件持久化”或“临时目录映射”。确认写入路径是否落在允许的目录范围内。检查写入操作是否被网络策略拦截部分平台的沙箱默认禁止访问外部存储服务。如果平台沙箱不支持写入可以考虑把产出结果通过 API 回传而不是直接落盘。5. Skill 机制让 Agent 具备可积累的专业能力5.1 Skill 是什么在多 Agent 系统中Skill 可以理解为一个“技能包”。它是一组经过组织化的提示词、脚本、配置文件和使用说明的集合。Agent 在面对特定任务时可以主动加载对应的 Skill而不是依赖通用能力硬解。Skill 解决的核心问题是通用大模型不可能精确掌握每个企业特有的技术规范、代码习惯和业务流程。通过 Skill可以把这些知识沉淀下来让 Agent 在需要时快速调用。可以把这个机制类比成给 Agent 装了一套内部工具库。与普通 Prompt 相比Skill 更结构化有明确加载条件和执行流程并且可以与脚本结合实现复杂操作。5.2 Skill 的标准组织结构一个典型 Skill 目录通常包含这些文件skill-root/ ├── SKILL.md # 技能说明Agent 判断何时加载该技能 ├── rules.md # 详细执行规则按步骤说明 ├── scripts/ # 可执行的辅助脚本 │ ├── validate.py │ └── generate.py ├── templates/ # 代码模板、提示词模板 │ └── backend_api.py.tpl └── examples/ # 少样本示例帮助 Agent 理解预期输出其中 SKILL.md 是最关键的文件。它决定了 Agent 是否能正确判断“该不该用这个技能”。SKILL.md 必须能回答三个问题这个 Skill 是做什么的。什么情况下应该使用它。使用它会改变什么风险是什么。5.3 编写一个可用的 SKILL.md下面给出一个简化但结构完整的示例演示如何定义企业后端接口生成 Skill。# Skill 名称企业后端 API 代码生成 ## 用途 根据需求描述生成符合公司规范的后端 REST API 代码包含 Controller、Service、DAO 三层结构以及对应的单元测试。 ## 适用场景 - 用户请求“新增一个用户查询接口”。 - 用户请求“给订单模块添加修改状态接口”。 - 需要批量生成 CRUD 接口时。 ## 不适用场景 - 用户只要求修改现有接口的字段不需要新建文件。 - 用户需求涉及复杂事务或多服务调用需要人工介入。 ## 执行步骤 1. 解析需求描述提取实体对象、字段名、方法类型。 2. 调用 scripts/generate.py传入实体名和字段列表。 3. 生成代码文件到 workspace/src/main/java/com/example/ 对应目录。 4. 自动生成单元测试保存在 workspace/src/test/java/ 目录。 5. 运行 mvn -DtestGeneratedTest test确认测试通过。 6. 如果测试失败根据错误信息修改代码最多重试 3 次。 7. 重试仍然失败时输出诊断信息并标记“需要人工介入”。 ## 关键约束 - 只允许生成 src/main/java 和 src/test/java 目录下的文件。 - 不允许修改 pom.xml、数据库脚本和部署配置。 - 生成的代码必须包含日志记录禁止直接输出用户敏感信息。 - 所有新增方法必须附带单元测试。这个 SKILL.md 看起来很朴素但它把所有关键信息都结构化表达了。Agent 读取后不需要“猜”该怎么做而是按步骤执行。5.4 自进化 Skill让 Agent 在任务中优化自身能力“自进化 Skill”是 Skill 机制里比较进阶的方向。它指的是Agent 在完成任务后不仅能产出业务结果还能根据任务执行情况自动沉淀新的技能或改进已有的 Skill 文件。举个例子。一个前端开发 Agent 在完成多个 Vue 项目后发现公司项目里大量使用某个组件库但通用 Skill 里没有收录。于是它可以在用户授权后从已完成任务中提取组件库的使用模式生成一个“Vue 组件库开发规范”的 Skill 文件添加到自己的技能库中。自进化 Skill 的实现思路并不需要多复杂的算法本质是通过一个“元技能”来控制# Skill 名称技能提炼器Skill Creator ## 用途 从最近完成的任务中提炼可复用的经验生成新的 Skill 或改进已有 Skill。 ## 触发条件 - 同一类任务在近期被成功完成 3 次以上。 - Agent 发现现有 Skill 无法覆盖需求但通过额外搜索或推理完成了任务。 - 用户主动要求“把这次的方法记录成技能”。 ## 执行步骤 1. 回顾最近任务记录筛选成功案例。 2. 提取通用模式去掉具体业务细节。 3. 参考现有 Skill 的 SKILL.md 结构生成新 Skill 草案。 4. 将草案提交到 Skill 仓库标记为“待人工评审”。 5. 人工评审通过后正式收录到 Agent 技能库。 ## 约束 - 禁止在 Skill 中写入个人敏感信息或未公开的业务数据。 - 新 Skill 必须经过人工评审不允许直接自动启用。自进化 Skill 的工程价值在于它让 Agent 的价值可以随时间积累而不是每次任务都从零开始。企业级落地时一定要加上人工评审环节避免 Agent 自动沉淀出质量不佳或隐含风险的技能。6. 人工介入何时打断 Agent 才是正确的工程决策6.1 人工介入不是失败而是设计的一部分很多做 Agent 项目的人把“需要人工介入”视为系统不够智能。实际上在企业级场景里人工介入是 Harness Engineering 的基础能力。关键问题是什么时候介入、如何介入、介入后如何恢复流程。如果完全没有人工介入机制Agent 一旦绕过预期路径可能导致未经评审的代码进入主干、权限被滥用甚至产生安全事故。相反如果人工介入点过多又会降低效率失去自动化意义。6.2 必须人工介入的典型场景从工程经验来看以下场景建议强制触发人工审批高权限操作涉及生产环境配置、密钥、数据库 DDL、用户数据读取。大范围重构变更代码量超过阈值或修改了核心模块架构。自动验证连续失败Agent 在多次重试后仍然失败需要人工判断是任务理解偏差还是环境问题。安全基线告警安全 Agent 发现高风险漏洞或敏感信息泄露。需求本身模糊Orchestrator 无法把高层需求映射到具体任务且置信度较低。在某次实际项目的代码评审流程里我推荐在三个固定节点插入人工审批任务分解完成、准备开始编码前人工确认任务拆解是否合理。Coder 完成代码并通过单元测试后人工进行 Code Review。变更合并到主干前进行最终审批。6.3 人工介入与 Agent 流程的衔接人工介入不是简单地把流程停下来。工程化做法是定义一个“审查任务”由系统自动收集上下文信息生成一个结构化审批请求推到人的工作台。审批请求应包含这些信息当前任务的背景和原始目标。Agent 已经完成的操作列表。改动文件清单与 Diff 统计。自动化检查结果编译、测试、安全扫描。Agent 自己的风险评估和推荐意见。人工审批后应该把决定作为一个事件发布回事件总线让相关 Agent 继续后续流程。如果人工驳回Orchestrator 需要根据拒绝原因重新规划或终止任务。7. 完整实战搭建一个最小可运行的企业级多 Agent 协同项目前面讲了不少概念这里用一个最小可运行的项目把整套流程串起来。项目目标是从一份自然语言需求完成一次代码生成、评审、沙箱验证和人工审批的完整链路。7.1 项目结构multi-agent-demo/ ├── agent_core/ │ ├── __init__.py │ ├── event_bus.py │ ├── agent.py │ └── orchestrator.py ├── sandbox/ │ ├── __init__.py │ └── executor.py ├── skills/ │ ├── api_generator/ │ │ ├── SKILL.md │ │ └── scripts/generate.py │ └── skill_creator/ │ └── SKILL.md ├── workflows/ │ ├── code_review.yaml │ └── approval.yaml └── main.py7.2 定义基础 Agent 类为了不引入重型框架这里用最简单的 Python 类来抽象 Agent。真实项目中你可以替换为 LangGraph、Dify 工作流或自研框架。# 文件路径agent_core/agent.py from abc import ABC, abstractmethod from typing import Any class BaseAgent(ABC): 所有 Agent 的基类定义执行入口和上下文管理。 def __init__(self, name: str, event_bus): self.name name self.event_bus event_bus self.context: dict[str, Any] {} abstractmethod def execute(self, task: dict[str, Any]) - dict[str, Any]: 执行子任务返回结构化结果。 pass def set_context(self, key: str, value: Any) - None: self.context[key] value def get_context(self, key: str) - Any: return self.context.get(key)这个类本身不复杂但它体现了 Agent 设计的一个重要原则不要把所有能力塞进基类。基类只负责通用上下文管理具体能力由子类实现。7.3 实现 OrchestratorOrchestrator 是整个系统的调度核心。# 文件路径agent_core/orchestrator.py from agent_core.event_bus import EventBus, EventType, AgentEvent from agent_core.agent import BaseAgent class Orchestrator: 负责任务拆解与调度。 def __init__(self, event_bus: EventBus): self.event_bus event_bus self.agents: dict[str, BaseAgent] {} def register_agent(self, role: str, agent: BaseAgent) - None: self.agents[role] agent def submit_goal(self, goal: str) - None: # 1. 编排者拆解任务这里简化为固定流水线 task_plan self._decompose(goal) # 2. 发布任务创建事件 self.event_bus.publish(AgentEvent( event_typeEventType.TASK_CREATED, sourceorchestrator, targetall, payload{goal: goal, plan: task_plan} )) # 3. 依次调度各 Agent 执行 for step in task_plan: role step[role] agent self.agents.get(role) if not agent: continue result agent.execute(step) if result.get(status) need_human: self._request_human_approval(result) def _decompose(self, goal: str) - list[dict[str, Any]]: # 实际项目中这里应由 LLM 完成这里使用固定模板 return [ {role: coder, task: f根据需求编写代码{goal}}, {role: reviewer, task: 对生成的代码进行评审}, {role: security, task: 对代码进行安全基线扫描}, ] def _request_human_approval(self, result: dict[str, Any]) - None: # 在真实系统中这里会推送到审批平台 print(f[人工审批] 任务需要人工介入。原因{result.get(reason)}) # 等待审批通过后继续 print([人工审批] 审批通过流程继续。)到这里一个最小可运行的 Agent 调度骨架就出来了。接下来可以运行一次验证多 Agent 之间的事件流转是否正常。python main.py7.4 运行流程与验证运行后预期输出大致如下[事件] 任务创建优化用户登录模块的密码重试逻辑 [coder] 开始编码根据需求编写代码优化用户登录模块的密码重试逻辑 [coder] 编码完成提交沙箱执行验证 [reviewer] 评审结果通过无阻塞问题 [security] 安全扫描未发现高风险告警 [人工审批] 任务需要人工介入。原因修改了认证核心逻辑 [人工审批] 审批通过流程继续。这个输出说明多 Agent 系统已经可以对任务进行拆解、执行、评审、安全扫描并在关键节点触发人工审批。8. 常见问题与排查思路在实际搭建多 Agent 协同项目时很容易踩到一些重复出现的问题。下面整理了一份排查表。问题现象常见原因解决思路Agent 之间的消息丢失事件总线没有统一超时和重试机制为事件消费增加确认机制失败重试Coder 反复修改代码但测试仍然失败任务目标描述过于模糊Agent 理解偏差引入 Reviewer 提前介入并补充单元测试预期沙箱执行命令报权限不足沙箱默认禁用部分系统调用审查沙箱配置按最小权限原则开放所需能力Agent 生成了大段无效重构任务边界定义不清晰在 Harness 配置中明确禁止修改目录和文件人工介入流程频繁触发自动验证规则过于严格区分“必须人工”和“允许 Agent 自动修复”的场景自进化 Skill 质量不稳定缺少人工评审机制新 Skill 必须经过人工确认后才能启用多 Agent 线程安全问题多个 Agent 同时写同一份工作区文件引入工作区锁或按 Agent 拆分独立沙箱目录沙箱中无法访问内部依赖网络策略未放行内部镜像源配置网络白名单代理只允许访问可信域名排查时可以按“先从 Harness 边界入手再看沙箱环境最后检查编排逻辑”的顺序大概率能快速定位问题。9. 最佳实践与企业级落地建议9.1 从“演示”到“生产”需要补齐的关键能力很多多 Agent 项目在 Demo 阶段很惊艳一上生产就崩。原因不是模型能力不够而是工程化能力没跟上。企业级落地时建议优先补齐这些能力可观测性每个 Agent 的输入、输出、工具调用、耗时、Token 消耗都要有日志追踪。推荐使用结构化日志便于后续复盘。配置中心所有 Agent 的模型参数、工具权限、沙箱策略都要能从配置中心动态调整不能写死在代码里。版本管理Skill 文件要纳入 Git 管理每次改动应该走类似代码评审的流程。成本控制多 Agent 协作的 Token 消耗远高于单 Agent。要设置预算上限并在执行前估算任务成本。9.2 安全边界设计多 Agent 协同项目天然面临更大的安全风险。Agent 越多工具调用越复杂攻击面也越大。安全边界设计建议遵循最小权限原则每个 Agent 只拥有完成任务所需的最小权限不要把所有 Agent 都配置为“管理员”。默认沙箱化所有代码执行都放在沙箱里即使该 Agent 的角色是“高可信”。强制审批点高风险操作必须有人工审批且审批过程要可审计。敏感信息过滤Agent 输入输出应该经过敏感信息过滤避免内部数据进入模型训练或被写入日志。9.3 Skill 管理的最佳实践每个 Skill 必须有明确的适用边界禁止编写“万能 Skill”。Skill 目录结构、命名规范要统一。Skill 的更新要经过评审不能直接在生产环境修改。定期统计 Skill 的使用率和成功率淘汰低质量 Skill。初始 Skill 应该由有经验的技术人员编写不要完全依赖模型自创。9.4 人工介入机制设计建议人工介入不是“紧急刹车”而是流程中的常规环节。建议把审批做轻让审批人能快速决策审批页面只展示最关键的上下文不要堆砌大段日志。提供“通过”“打回修改”“终止任务”三个选项而不是开放文本留言为唯一操作。所有审批记录要留痕并与任务关联。对高频触发人工介入的任务应该主动复盘看是否可以通过调整 Harness 配置来减少无效介入。10. 总结与后续学习方向本文围绕 Harness Engineering 这一思路拆解了企业级多 Agent 协同项目的核心构成。从多 Agent 协作模式、沙箱隔离、Skill 机制、人工介入到最小可运行项目的代码实现再到常见问题和最佳实践已经覆盖了一个生产级 Agent 系统最重要的工程节点。如果要从这里继续深入建议优先研究三个方向第一是具体框架的使用比如 LangGraph 或 Dify 等平台如何承载上述设计第二是沙箱方案选型深入理解 Docker 安全配置、微虚拟机和 WASM 沙箱的边界第三是 Skill 体系建设的规模化方法也就是在一个团队里如何长期沉淀和维护高质量技能库。最后想提醒一点多 Agent 项目的成败不完全取决于模型多聪明而取决于你能不能让它在一个明确的轨道上发挥能力。Harness Engineering 的每一步设计本质上都是在回答“如何让 Agent 既强大又可控”。在企业级场景里后者往往才是真正的竞争力。