4.1 Harness Action Plane
4.1.1 从模型意图到环境事实
一个完整的行动链不应从“调用 Tool”开始,也不应在“返回文本”处结束: 这条链路建立三个必须区分的事实:- 模型看见某个工具,表示 Tool 描述进入了当前 Context。
- Harness 注册某个工具,表示系统知道如何调用和解析它。
- 当前用户和任务获得执行授权,才表示这次具体行动可以发生。
4.1.2 用统一行动契约约束不同能力
模型可能通过 Function Calling 请求 Tool,也可能要求 Shell、浏览器、Computer Use 或远程 Agent。Harness 应先把这些不同表达转换为统一 Action Request:- 成功、失败、未知或部分完成状态;
- 结构化数据与面向模型的紧凑 Observation;
- 原始结果、日志或 Artifact 的稳定引用;
- 错误类别、可重试性和是否已产生副作用;
- 实际执行身份、环境、时间、版本和成本;
- 对 Task State 的候选 Patch;
- 可供 Verifier 使用的环境证据。
HarnessAgent 运行形态的共同边界。本地工作区可以在可信环境中直接执行;嵌入式服务通常接入企业工具和权限网关;长任务 Worker 则在可恢复的 Session 与隔离环境中执行。无论谁承载,企业都要知道一次行动以谁的身份、在哪个环境、依据什么策略发生,并能够关联到最终 Outcome。
4.1.3 案例:创建变更单与执行发布是两个 Action
漏洞修复 Agent 已经生成补丁和验证报告。此时“创建变更单”与“发布生产环境”不能被包装成一个模糊工具,因为它们的身份、风险、可逆性和审批要求完全不同。创建变更单的请求可以表示为:4.2 工具、MCP 与远程 Agent
4.2.1 Function Calling、MCP 与 A2A 的职责边界
这三者处理的是不同连接层次:- Function Calling 让模型用结构化形式表达“想调用哪个能力、提供什么参数”。它是模型与 Harness 之间的意图接口。
- MCP 让 Agent Host 以标准方式发现和连接工具、资源等外部能力。它是 Harness 与能力提供方之间的连接协议。
- A2A 面向拥有独立任务循环、状态和自主性的远程 Agent。它传递任务、消息、状态和 Artifact,而不只是执行一个函数。
4.2.2 面向 Agent 的 Tool 设计
Tool 是 Harness 交给模型的行动单元。模型能否正确使用,取决于 Tool 是否提供清晰、稳定、可约束的语义,而不仅是 API 能否调用。 一个适合 Agent 的 Tool 应做到:- 名称和描述说明业务目的、适用条件与非目标。
- 输入 Schema 使用明确类型、枚举、边界和示例,避免让模型拼接任意请求。
- 输出区分结构化结果、面向模型的摘要和原始证据引用。
- 明确是否只读、是否有副作用、是否可逆、是否支持预览和幂等。
- 错误采用稳定分类,告诉 Harness 能否重试、需要修正参数还是转人工。
- 将认证和 Secret 留在执行侧,不放入 Tool 描述或模型 Context。
4.2.3 Registry、Gateway 与渐进式披露
Tool、MCP Server 和 Remote Agent 都应进入统一或可关联的能力目录。Registry 负责能力元数据、所有者、版本、健康、作用域和依赖;Gateway 负责协议入口、身份、凭证、路由、限流、审计和策略执行;Harness 则根据任务选择候选能力,并向模型渐进式披露。 当能力数量较少且信任边界简单时,Harness 可以直连;当多个 Agent、框架和团队共享大量能力时,Registry 与 Gateway 可以避免凭证和治理逻辑在每套 Harness 中重复。具体网关实现属于运行与平台治理层,本文只固定 Harness 所依赖的发现、身份、权限和审计契约。4.2.4 Tool、MCP Server、Skill、Subagent 与 Remote Agent 的边界
这张表能避免两种常见混淆。把固定 API 包装成“Agent”不会自动获得规划和恢复能力;把复杂远程 Agent 当作同步 Tool,则会丢失任务状态、异步事件和 Artifact 语义。
4.2.5 连接远程 Agent
本系列第二篇已经定义 Delegation 的编排语义。跨系统委派还要增加互操作契约:- 远程 Agent 的身份、能力声明、版本和服务边界;
- 任务目标、输入、上下文引用与数据使用限制;
- remote_task_id 与本地 task_id 的关联;
- 状态、进度、消息、Artifact 和错误的映射;
- 超时、取消、幂等、重试与回调语义;
- 凭证委派、租户边界和可审计的代表关系;
- 结果 Schema、证据和最终验收标准。
4.3 执行环境与 Sandbox 契约
Agent 不只通过业务 API 行动,还可能直接使用 File、Shell、Code Interpreter、Browser 和 Computer Use。这些能力给模型提供了通用操作空间,也显著扩大了副作用和攻击面。Harness 需要声明完成任务所需的 Environment,Runtime 与 Sandbox 则负责真正创建、隔离和销毁它。
Tool 常把复杂操作压缩成受 Schema 约束的业务动作,环境接口则更通用、更灵活。能用窄 Tool 完成的高风险动作,通常不应优先开放通用 Shell 或 Computer Use;当企业需要处理长尾应用和非结构化工作区时,再用 Sandbox 把通用能力限制在可接受边界内。
4.3.1 声明并兑现 Environment Contract
Harness 不应假定“本机一定有某目录、某版本依赖或可访问公网”,而应提交 Environment Contract:
托管 Harness 与自托管 Sandbox 可以组合:推理和任务编排由平台管理,实际工具执行留在企业环境。关键是 Session、Harness 与 Sandbox 之间使用稳定事件、状态和身份契约,不能把长期 Secret 或完整企业数据复制到托管控制侧。
环境可以按 Agent、Session、Task 或 Action 隔离。粒度越细,污染和横向移动风险越低,但创建成本和状态传递成本越高。在线多租户任务通常至少按 Task 或 Session 隔离;同一用户的长期工作区可以持久化,但要把可共享基础镜像与私有可写层分开。
环境生命周期包括:创建、准备、挂载输入、运行、快照、恢复、清理和销毁。销毁前应明确 Artifact 和证据已经转存,临时凭证已经撤销;恢复时要验证镜像、依赖、文件版本和外部对象是否仍与 Checkpoint 一致。
HarnessAgent 通过可插拔 FileSystem 和 Sandbox 适配本地、远程或企业自建环境。应用可以让每个 Session 获得独立隔离环境,也可以在受控条件下复用缓存与基础设施;具体实现不同,Harness 依赖的仍是同一 Environment Contract。
4.3.2 让代码修改只发生在隔离工作区
Framework 路径中,应用团队可以把 Sandbox 作为 Harness 的文件系统实现,而不是让模型直接操作宿主机。下面的 AgentScope 示例为每个 Session 绑定 Docker 文件系统;项目规则、Skill 和输入文件投影到隔离工作区,补丁与测试结果再作为 Artifact 取回。4.3.3 Secret、网络与数据出站
Secret 不应出现在 System Prompt、Tool Schema、Task State 或模型可见环境变量中。执行侧应根据 Action、身份和目的获取短时凭证,只注入目标工具或进程,并记录使用而不记录密文本身。 网络策略应默认限制出站目标、协议和数据量。浏览器访问的网页、下载文件和工具返回必须被标记为不可信内容;高敏数据出站需要额外策略或审批。Sandbox 防止进程越界,Policy 决定业务上是否允许,二者缺一不可。 运行时资源调度、镜像供应链、快照后端、容灾和规模化 Sandbox 属于后续运行与治理工作;本文的 Build 交付物是可验证、可移植的环境与隔离要求。4.4 Permission、HITL 与安全控制
4.4.1 让身份、资源与风险共同参与决策
Harness 需要同时记录三类信息:发起任务的用户或服务身份、发起行动的 Agent 版本、实际执行 Tool 或 Sandbox Action 的 Runtime 身份。一次调用可以使用服务身份,也可以传递用户委派,但必须明确数据访问和副作用最终归属于谁。 权限决策至少考虑:主体、租户、任务目的、能力、参数、目标资源、环境、当前阶段、数据敏感度、影响范围、可逆性、预算和历史审批。仅按 Tool 名称做静态白名单,无法区分“读取一条测试记录”和“导出整个生产库”。 Harness 可以将策略结果统一为三类:- ALLOW:当前条件下可直接执行,并记录决策依据。
- DENY:无论模型如何解释都不得执行,向 Loop 返回结构化原因和允许替代项。
- ASK:动作可以执行,但需要指定的人或系统确认。
4.4.2 在真正需要判断的位置引入 HITL
HITL 可以出现在三个层次:- Plan 审批:在进入执行前确认目标、范围、方案和影响面。
- Action 审批:对某次具体 Tool、环境或远程 Agent 调用进行批准、拒绝或修改。
- 结果验收:对高影响 Artifact 或业务结果做最终签署。
4.4.3 把 HarnessAgent 审批接入企业界面
企业应用可以让HarnessAgent 使用 DEFAULT 权限模式,并把规则判定为 ASK 的 Tool 请求转换为审批事件。审批界面展示关联 Task、调用身份、Tool、参数、目标资源和预计影响;后端完成确定性策略校验后,再把批准或拒绝结果交回当前 Session。
4.4.4 Guardrail 与 Prompt Injection 防护
Guardrail 可以部署在输入、Context 构建、Action 请求、Tool 结果和输出阶段,但它不应成为唯一安全边界。对确定可编码的权限和资源限制,应使用 Policy 与 Sandbox;模型或分类器适合识别复杂语义风险、敏感内容和可疑意图,并把结果作为额外信号。 Prompt Injection 的关键防线是区分指令与数据。网页、邮件、文档、MCP Server、工具结果和远程 Agent 返回的内容都属于不可信输入,不能改变平台政策、授权范围或当前 Tool Set。Harness 应保留内容来源,限制外部文本进入高优先级指令层,对数据外传和高风险 Action 做独立授权,并在必要时隔离读取与执行阶段。 完整威胁模型、身份体系、MCP 安全、Sandbox 逃逸和合规审计将在“治理(Governance)”篇展开。本节给出的是 Build 阶段必须嵌入 Harness 的执行控制点。4.5 Streaming、Channel 与交互协议
4.5.1 面向任务语义的事件流
长任务如果只在结束时返回一段文本,用户无法知道 Agent 当前在做什么、是否等待审批、是否遇到阻塞,也无法及时纠偏。Harness 应产生一组与内部事件对应、经过脱敏的外部语义事件:
模型内部的隐藏推理不需要通过 Streaming 暴露。用户真正需要的是任务状态、可见说明、行动、证据和可操作选项。
4.5.2 Channel 的职责
Channel 是 Agent 与 Web、App、IDE、CLI、企业 IM 或其他入口之间的适配层。它不负责重写 Harness,而是处理:- 将外部用户和组织身份映射到平台身份;
- 将消息线程映射到 Session,并选择或创建 Task;
- 把附件、回复、按钮和命令转换为统一输入事件;
- 将 Harness 事件转换为渠道支持的消息、卡片和状态;
- 在用户从一个入口切换到另一个入口时保持任务连续;
- 实施渠道级内容限制、速率、脱敏和审计。
4.5.3 AG-UI 与 A2UI
AG-UI 适合表达 Agent 与应用之间的双向、流式交互事件,使前端不必依赖某个 Framework 的内部对象。它可以承载运行生命周期、文本、工具、状态和中断等语义。采用时,企业仍需决定内部事件到外部事件的映射、字段脱敏、身份绑定和恢复游标。 A2UI 适合让 Agent 输出声明式界面,例如表单、卡片、列表和动作。客户端使用本地受信组件目录渲染,而不是执行模型生成的任意代码。A2UI 描述“界面是什么”,AG-UI 处理“Agent 与应用如何交换事件”;A2UI Payload 可以通过 AG-UI 或其他传输发送,两者并不互相替代。4.5.4 让事件可以续传、限流和按身份展示
事件流必须假定网络会断开、客户端会重复连接、消费者速度不同。每个事件要有单调序号或可恢复游标;客户端重连时从最后确认位置续传,服务端支持去重;快消费者可以实时接收增量,慢消费者可以先读取状态快照再补充关键事件。 对于高频文本 Token 或细粒度工具日志,系统可以合并、采样或仅在调试模式下发送;状态、审批、Artifact 和终态事件则不能因背压被丢弃。用户发出 Cancel 或 Interrupt 后,Channel 要尽快确认请求已经进入状态机,并区分“已收到取消”和“底层 Action 已安全停止”。 同一 Task 在不同 Channel 中显示的内容可能不同。开发控制台可以查看详细 Tool 和 Trace,面向客户的应用只展示业务进度;审批人能查看影响对象,普通观察者只能看到等待状态。事件发布前要根据接收者身份与 Channel 能力生成视图,不能把内部 Trace 原样广播。 协议的价值是降低适配成本,语义契约才决定体验能否一致。企业应先稳定 Task、Event、Approval 和 Artifact 模型,再选择 AG-UI、A2UI、WebSocket、SSE 或消息平台接口作为具体承载。4.5.5 用 HarnessAgent 事件承载持续任务
HarnessAgent.streamEvents 把一次 Session 中的模型、工具和状态变化暴露为流。应用将这些事件写入带单调序号的 Event Store,再通过 SSE、WebSocket 或消息平台向客户端投影;客户端断线后从最后确认的游标续传,而不是要求原 Worker 和原连接一直存在。
sessionId 关联到 Task、租户和审批单,并针对不同 Channel 与接收者生成安全视图。
当 Harness 等待 Tool 审批、用户输入或外部任务时,任务进入显式 WAITING 状态;idle、流结束或模型停止都不能单独判定完成。恢复时,Runtime 使用相同 RuntimeContext 重新进入 Harness,先核对 Task State、外部系统和剩余授权,再继续行动。
4.6 Observability、Evaluation 与效果闭环
4.6.1 用端到端 Trace 连接决定、行动与结果
Agent 的最终质量来自模型与 Harness 的组合,问题可能发生在 Context、计划、工具、权限、环境、状态或验证任一环节。Trace 因而不能只记录模型输入输出。一次 Task Trace 至少应关联:- 哪些内容默认记录,哪些仅在调试模式记录;
- 敏感字段如何分类、脱敏、加密和控制保留期;
- Trace 如何关联 Agent 版本与 Context Manifest;
- Outcome 从哪个业务系统或人工反馈写回;
- 采样后如何保留错误、高风险和低频长尾任务;
- 多个 Agent、Runtime 和远程系统之间如何传递 Trace Context。
4.6.2 区分单次完成门禁与跨版本评估
需要再次区分两套系统:
Evaluation Harness 必须固定或披露模型、推理设置、Harness、工具版本、预算、重试、环境和评分规则。否则两个版本的分数差异可能来自运行条件,而不是所评估的 Harness Patch。
本系列第二篇介绍的 Verifier 是单次任务完成门禁,运行在 Agent Harness 内部;Evaluation 则对多个样本和版本进行质量判断。Verifier 可以成为 Evaluation 的数据来源,Evaluation 也可能发现某类 Verifier 过松或过严,但不应把昂贵的发布评估器直接嵌入每次线上任务。
对高风险任务,Verifier 关注可交付底线;对 Agent 版本,Evaluation 还要判断相对改进、退化分布和长尾风险。人工反馈也不是天然真值,需要区分用户偏好、业务结果和操作便利性,并与环境证据结合解释。
三层评测对象。
只评最终结果可能掩盖高成本或高风险轨迹;只评单步又可能惩罚有效探索。企业需要同时衡量任务成功率、完成质量、人工接管率、工具错误、权限事件、延迟、成本和业务价值,并按任务类型和风险分层。
从 Trace 到 Harness Patch。
效果闭环不应从单条失败直接改 Prompt。更稳健的过程是:
常见 Patch 与根因应一一对应:缺少事实时调整 Context 或 Knowledge;错误经验反复出现时修复 Memory;不会执行稳定方法时新增或修订 Skill;工具误用时改进 Tool Schema 或权限;无进展时调整 Loop、Plan 或模型;环境不一致时修复 Environment Contract;完成误判时强化 Verifier。只有确定模型能力本身不足时,才优先更换模型或路由策略。
回归集必须同时包含原失败用例、相邻正常用例和安全对抗用例,防止局部补丁损害其他任务。模型升级后,还应重新检查旧 Harness 中的补偿逻辑,删除已经失效或阻碍新模型的规则。
4.6.3 案例:从一次错误审批到 Harness 修复
假设线上 Trace 显示,修复 Agent 在创建变更单后,把用户此前对生成草稿的同意错误解释为允许生产发布。问题表面是一次越权,沿因果链检查后可以定位到:4.6.4 不同 HarnessAgent 运行形态如何形成反馈闭环
四种形态可以使用同一套 Evaluation Harness。它接收带版本的 Trace、Outcome、用例和评分器,对不同
HarnessAgent 版本进行一致比较。运行形态决定谁承载执行,统一评估闭环决定系统是否真的变好。