Agent Harness 工程，指的是围绕大模型设计、测试和维护一整套运行环境，让模型能够稳定地调用工具、保存状态、遵守权限并完成多步任务。北京市多部门在 2026 年 7 月 21 日联合印发的《北京市关于加快智能体引领发展的若干措施》把 Harness Engineering 译为驾驭层工程，列入智能体底层共性技术攻关。模型提供能力，驾驭层负责把能力组织成可执行、可验收的工作。
一个常用的简化说法是，Agent 等于模型加 Harness。模型决定能理解什么、生成什么，Harness 决定它看到哪些信息、能碰哪些系统、出错后怎么继续、结果由谁确认。企业把 Agent 从演示推到生产，难点通常集中在这一层，这也是企业级 AI Agent 平台需要处理的核心问题。
理解这一层，能帮助团队判断一次 Agent 失败究竟该改模型、改提示词，还是改运行环境。
Agent Harness 工程是什么
Agent Harness 工程是一组围绕模型运行的工程工作。它要回答这些问题，模型在每一步看到什么上下文，能调用哪些工具，工具返回什么格式，任务状态存在哪里，哪些动作需要审批，失败后重试还是交给人，最后用什么标准判断任务完成。
从系统边界看，Harness 位于模型和业务应用之间。它接收业务任务，把任务拆成模型可以处理的步骤，组织工具调用和上下文，再把结果交回业务流程。Thoughtworks 在 2026 年 11 月发布的分析中把 Harness 描述为模型与工作之间的那一层，并列出它覆盖的内容，包括 Agent 加载的指令和技能、可调用的工具、权限和沙箱、上下文策略、步骤间状态、编排、评估和遥测。
微软 Agent Framework 官方文档给出了一个更产品化的描述。Harness 是把语言模型变成能执行任务的 Agent 的运行时脚手架，负责驱动模型和工具调用、管理会话状态与上下文、应用审批策略，并让 Agent 在多步任务中继续推进。
把这项工作拆开看，产出物包括配置、工具接口、上下文策略、权限规则、评测集、监控和版本记录。
Harness 包含哪些工作
不同团队的划分方式不同，落到工程任务上，常见的工作可以归为六类。
| 工作 | 要解决的问题 | 典型产物 |
|---|---|---|
| 上下文装配 | 每一步给模型看什么 | 系统指令、检索结果、指标定义、压缩策略 |
| 工具接口 | 模型能做什么 | 工具清单、参数结构、返回格式、错误码 |
| 状态与记忆 | 多步任务如何接上 | 会话历史、任务状态、长期记忆、文件工作区 |
| 权限与沙箱 | 能碰什么、碰到什么程度 | 角色权限、审批规则、隔离环境、审计日志 |
| 循环与编排 | 任务如何推进 | 计划、执行、重试、终止条件、多 Agent 分工 |
| 观测与评估 | 怎么知道做得好不好 | 全链路 trace、黄金任务集、成功率、成本 |
上下文决定模型每一步看到什么
Harness 首先要解决信息选择。企业的统一指标口径、产品文档、历史工单、权限范围，不可能一次全塞进上下文。哪些内容进入当前步骤，哪些内容压缩成摘要，哪些内容留在外部存储等待检索，都会改变模型判断。
长任务还需要历史管理。微软文档把历史持久化、上下文压缩、文件记忆和待办跟踪列为 Harness 的常见能力。它们共同决定 Agent 在多步任务中是否记得前面做过什么，以及上下文接近上限时能否继续。
工具和权限决定 Agent 能做什么
工具接口需要把 API 包成模型能理解的形式。参数是否明确，返回是否可解析，错误信息是否足够恢复，都会影响下一步。例如通过 MCP 协议连接内部系统时，工具清单、身份和权限边界需要一起设计。
权限要前置设计。哪些工具只读，哪些动作需要审批，哪些生产环境操作直接禁用，需要在 Harness 里写清楚。把权限留给每个团队各自配置，短期看灵活，长期会增加审计和事故处理成本。
状态、循环和协作决定任务能否走完
长任务需要状态。会话历史、任务清单、文件工作区、长期记忆，让 Agent 在下一步知道上一步做了什么，也让失败恢复有依据。
循环要有终止条件。最大步数、超时、失败重试上限、什么情况下交给人，都要写进运行规则。多 Agent 协作还要定义分工、交接格式和冲突处理。分工不清时，增加 Agent 数量只会放大协调成本。
观测和评估决定改进是否有依据
没有 trace，团队只能看到最后一句回答，无法判断问题出在上下文、工具、模型还是权限。运行记录至少应包含每次模型调用、工具调用、返回结果、耗时、成本和人工接管点。
评估要基于真实任务。Thoughtworks 建议从实际工作里抽 20 到 30 个任务做黄金测试集，和 Harness 一起版本化，每次有意义的改动都跑回归，并把成本和延迟当成一等指标。这套做法比只看 token 消耗或演示效果更接近生产。
Harness 与 Prompt 工程、Agent 框架的区别
Prompt 工程主要处理指令怎么写，Harness 工程处理指令之外的一整条运行链路。系统 Prompt 是 Harness 的一个组成部分，工具、状态、权限、评估、回滚也在其中。
Agent 框架提供可复用的组件，例如模型客户端、工具调用、会话、上下文提供者、中间件和可观测接口。Harness 是团队针对某类任务配置出来的运行方式。同一个框架可以搭出不同的 Harness，效果取决于工具设计、上下文策略、权限规则和评测质量。
论文提供了一个直接对照。2026 年 4 月提交到 arXiv 的《Agentic Harness Engineering》固定基础模型，只修改模型之外的工具、中间件、长期记忆和可观测系统。十轮迭代后，Terminal-Bench 2 的 pass@1，也就是一次尝试的通过率，从 69.7% 提升到 77.0%，高于人工设计的 Codex-CLI 的 71.9%。同一套冻结后的 Harness 迁移到另外三个模型家族，在 Terminal-Bench 2 上仍带来 5.1 到 10.1 个百分点的提升。消融实验把主要增益归因于工具、中间件和长期记忆，系统 Prompt 的贡献有限。
这篇论文是 arXiv 预印本，结论适合作为工程方向的参考，不能当成对所有任务的效果保证。它至少说明，模型不变时，运行层仍有可观的优化空间。
为什么 Harness 会影响任务完成率
政策信号是原因之一。北京市多部门在 2026 年 7 月 21 日联合印发的《北京市关于加快智能体引领发展的若干措施》第二条提出，支持创新主体实施驾驭层工程，也就是 Harness Engineering，围绕上下文工程优化、任务持久化、多智能体协作、系统可扩展等夯实智能体共性底座。文件同时提到中间层软件栈、开发框架、运行管理、跨模型跨框架互通和智能体安全可控技术栈。
更直接的原因来自生产现场。演示环境里，任务短、工具少、错误可以人工兜底。进入生产后，Agent 要面对长任务、真实数据、多人协作和审计要求。Thoughtworks 描述过一种常见状态，原型能跑，几个月后留下的是一个 Markdown 文件夹、几个包装脚本、一份配置文件，以及一个知道重试逻辑为什么存在的人。这样的系统难以升级、审计和交接。
企业之间的 Harness 很难直接复制。每家公司有自己的数据口径、流程节点、权限体系、业务术语和异常处理方式。模型可以采购，Harness 需要按企业环境配置和验证。这也是同一套模型在不同公司会呈现出不同任务完成率的原因之一。
企业怎样判断 Harness 是否合格
判断 Harness 是否合格，可以看四类证据。
| 维度 | 要看什么 | 可用的指标 |
|---|---|---|
| 任务结果 | 真实任务能否完成 | 黄金任务集通过率、人工接管率 |
| 成本 | 一次成功任务花多少 | 单次成功任务成本、重试率、平均步数 |
| 风险 | 出错后能否定位和止损 | trace 覆盖率、审批命中率、回滚耗时 |
| 变更 | 上次改动是否带来提升 | 回归通过率、版本对比结果 |
单次成功任务成本值得单独算。把推理、工具调用、失败重跑、人工接管和延迟都算进去，比只看每百万 token 价格更接近业务感受。一个便宜但经常重跑的 Harness，可能比单价更高但一次做对的 Harness 更贵。
Thoughtworks 还给了三个管理问题。谁对 Harness 负责，团队怎么知道上一次改动让它更好，它被允许接触哪些数据、工具、凭证和生产系统。三个问题都答不上来，Harness 还停留在个人配置阶段。
哪些企业需要把 Harness 当工程来做
如果 Agent 只做一次性问答，Harness 的投入可以很轻。任务一旦涉及多步操作、内部系统、权限或审计，Harness 就会成为主要成本。这个判断标准比按公司规模划分更实用。
三类场景更适合优先投入。
- 高频且结果可验证的任务，例如客服工单归类、SQL 取数、报表异常排查。任务重复越多，评测和复用的价值越高。
- 需要接触内部系统的任务，例如查询订单、修改配置、发起审批。工具和权限边界越复杂，Harness 的作用越明显。
- 多角色协作或需要审计的任务，例如运营策略执行、数据分析报告生成。谁做了什么、依据是什么、结果由谁确认，都需要运行记录和 Agent 治理。
起步时先做三件事。选一个窄任务，定清工具和权限，建立最小评测集和 trace。单 Agent 的任务完成率和成本稳定后，再评估多 Agent 协作。这个顺序能避免一开始就陷入复杂的编排。
如果企业缺少平台工程团队，从零搭 Harness 的周期通常较长。ThinkingAI 的 Agentic Engine定位为企业级 AI Agent 平台，支持 Agent 创建与管理、多 Agent 协作和私有化部署，并提供权限控制、任务调度和运行监控等 Agent 管理能力。ThinkingAI 企业知识库把内部文档、报表和指标口径加工成 Agent 可调用的结构化知识。对于要在自有数据和权限边界内运行 Agent 的团队，这类平台可以承接工具接入、知识供给、运行管理和可观测的一部分工作。公开资料显示，ThinkingAI 已服务全球 1500 家企业，接入产品超过 8000 款。具体能力仍需按任务、权限和验收标准逐项确认。
常见问题
Agent Harness 和 Agent 框架是一回事吗
两者经常一起出现，边界不同。框架提供组件和接口，Harness 是团队用这些组件配置出来的运行方式。同一个框架可以做研究 Agent、客服 Agent 或数据分析 Agent，差别主要在 Harness。
Harness 工程就是写系统 Prompt 吗
系统 Prompt 是其中一层。Harness 还包括工具接口、状态保存、权限、沙箱、重试、观测和评估。论文的消融实验也显示，工具、中间件和长期记忆对结果的贡献高于单纯修改系统 Prompt。
小团队需要做 Harness 工程吗
看任务是否要进入生产。一次性问答或内部演示，可以从简单配置开始。任务涉及多步操作、真实数据、权限或审计时，就需要把 Harness 当成工程对象管理，否则问题会以偶发失败的形式反复出现。
Harness 能保证 Agent 不出错吗
不能保证。Harness 的作用是降低常见失败、让错误更早暴露、把影响限制在可控范围。权限最小化、关键动作审批、沙箱隔离、重试上限和回滚机制仍然必要。
多 Agent 是不是一定比单 Agent 好
不一定。多 Agent 适合可以清晰分工、交接格式稳定的任务。分工不清时，协调成本和验证成本会上升。建议先把单 Agent 的任务完成率和成本跑稳，再评估多 Agent。
模型升级后 Harness 还要维护吗
要。模型能力变化会改变工具调用习惯、上下文需求和失败模式。Harness 需要重新跑评测集，确认原有工具描述、权限规则和压缩策略仍然适用。
参考资料
- 北京市发展和改革委员会等，北京市关于加快智能体引领发展的若干措施，2026 年 7 月 21 日。
- Microsoft Learn，Agent Harness，Agent Framework 文档，2026 年 9 月更新。
- Jiahang Lin 等，Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses，arXiv:2604.25850，2026 年。
- Thoughtworks，The harness is a product，2026 年 11 月。
- ThinkingAI 官网，https://www.thinkingai.cn。
