模型已经够强，为什么 Agent 还离不开 Harness？

1、核心结论

2026 年的 Agent 竞争，正从“谁的模型更聪明”转向“谁能把模型组织成一套可靠系统”。模型负责推理和生成，Harness 负责让它看见环境、调用工具、保留状态、控制权限、发现错误、恢复任务，并在真正产生外部影响之前停下来。

“通宵跑任务”在技术上已经越来越可行。它的正确形态，是预先放行低风险、可逆、规则明确的动作，同时把人工闸门留给付款、发信、发布、删除、改权限和可能泄露数据的时刻。确认少了，责任边界反而要更清楚。

生产任务的主要失败来源，往往不是模型无法生成答案，而是目标没有变成验收条件、上下文遗漏既有约束、执行结果未经真实环境验证，或者系统把“工具调用成功”误当成“用户已经得到结果”。模型升级能减少局部错误，却不会自动补上这条责任链。

2、Harness 到底是什么

Harness 原意是挽具或线束。在 AIGC 语境里，它不是新的基础模型，而是包在模型外面的运行时与治理层。最小版本只是一个循环：模型提出工具调用，系统执行工具，把结果送回模型，直到模型认为任务完成。

生产级 Harness 则要多解决八类问题：任务如何拆分、上下文如何装载、工具如何暴露、权限如何控制、过程如何持久化、失败如何重试、结果如何验证、全程如何追踪。

OpenAI Agents SDK 已把 agent loop、tools、handoff、session、guardrails、human-in-the-loop 和 tracing 作为一组基础能力；微软最新文档也把持久待办、上下文压缩、文件记忆、作用域文件访问、常驻审批和 OpenTelemetry 列为典型 Harness 组件。

模型能力决定上限，Harness 决定这个上限能否稳定地被调用。

3、发展到了哪一步

目前行业已经跨过“会调用工具”的演示阶段，进入生产化与组织化阶段。但不同产品差距很大，可以用五级成熟度来判断：

前沿系统已经触及 L4。OpenAI 的 Symphony 实验把工单系统作为控制平面：每个任务有独立工作区，依赖解除后自动启动，崩溃或停滞可以重启，人主要审核结果而不是盯着每一轮对话。

OpenAI 另一项内部实践显示，在为 Agent 充分改造的代码库里，三个工程师用约五个月让智能体生成约一百万行代码和 1,500 个 PR。关键并非一句更长的提示词，而是把文档、架构规则、浏览器、日志、测试和评审反馈全部变成 Agent 可读、可执行的反馈回路。

但这并不表示 L4 已经普及。Anthropic 在长时应用开发实验中仍发现：上下文越长，智能体越容易保守、丢失连贯性；规划器、生成器、评测器的分工能改善多小时任务，却增加延迟、Token 和编排复杂度。模型升级后，旧脚手架甚至会成为负担，所以成熟 Harness 的另一项能力是持续删减无效流程，而不是只会叠加 Agent。

4、ChatGPT Agent 的演进

2025 年 7 月发布的 ChatGPT Agent，是理解 Harness 的典型样本。它把 Deep Research 的多步研究、Operator 的可视化浏览器、终端、有限网络访问和连接器放进同一个任务循环；涉及外部影响的动作会触发确认，敏感网页场景另有 Watch Mode。能力与安全边界见 ChatGPT Agent System Card。

截至 2026 年 7 月，OpenAI 的最新产品结构把能力分成三种工作面：Chat 负责快速问答，Work 负责研究、分析以及文档、表格、演示、报告和 Site 等完整交付物，Codex 负责软件工程。官方说明同时强调，具体能力取决于套餐、工作区设置与使用界面。参见 ChatGPT Work and Codex。

这个变化体现的是 Harness 产品化：系统根据任务类型选择环境、工具和权限。云浏览器目前面向受支持的公开网页，不能接收凭证、登录网站或完成付款；桌面内置浏览器可以在用户授权下处理登录态与下载，但凭证仍应由用户在浏览器内输入。参见云浏览器说明与桌面内置浏览器说明。

ChatGPT Agent 最重要的遗产，不是一个按钮，而是把浏览、研究、执行、交付、暂停和恢复组合成了一套用户可理解的工作协议。

5、一条完整 Harness 流程

一个成熟任务不是“提示词进去、答案出来”，而是一条循环管线。每一步都可能回到前面重规划，也可能在权限闸门处暂停后持久化，数小时后从原状态恢复。

OpenAI Agents SDK 的人工审批实现正体现了这套思想：工具可声明是否需要审批；任务暂停后把状态序列化，批准或拒绝后从原顶层任务继续；同一运行中还可以把某类决定设为持续批准。审批因此不再等于“每一步都问人”，而是可配置、可持久化的策略。

6、人还需要做什么

人的工作没有消失，而是从亲自执行每个步骤，转向设计任务系统和承担最终责任。越成熟的 Harness，越会把人从重复确认里移开，把注意力集中在模型无法自行合法决定的事情上。

7、以 ChatGPT Work 为例

假设用户要求：“比较五家供应商，读取内部采购记录，做一份成本表和管理层演示，并起草给首选供应商的议价邮件。”这看似一句话，实际会触发完整 Harness。

这就是成熟的人机分工：人不需要盯着它搜索每个网页，也不需要批准每次读文件；但系统不会自行决定公司愿意承担的合同风险，更不应在没有审核的情况下替公司发出承诺。

8、为什么还不能无人值守

Harness 显著提升了连续执行能力，却没有消除基础模型的概率性。任务越长，微小错误越可能累积；工具返回异常、网页改版、API 限流、状态过期，都可能让原计划失效。

这类失败让我更看重语义验收而不是工具成功率：来源是否是正确版本、数字是否属于同一口径、结论是否真的回答了任务。Harness 最容易制造的错觉，是把可观测的流程完整，误当成不可直接观测的判断正确。

最大的结构性风险是提示注入。智能体在网页、邮件或文档中看到的文字，既可能是资料，也可能是攻击者写给 Agent 的恶意指令。ChatGPT Agent 发布时采用确认、监控、Watch Mode、终端网络限制和默认关闭记忆等措施，正说明能操作真实世界的 Agent 必须假设外部内容不可信。

第二个风险是“评测幻觉”。自动检查可以覆盖格式、测试和已知规则，却很难完全评价战略、审美、可用性和事实是否遗漏。Anthropic 的长任务实验即使加入独立评测器，仍会漏掉布局、交互与深层功能问题。

第三个风险是复杂度反噬。多 Agent、长记忆和反复评测会带来更高成本、延迟和更多故障面。好的 Harness 不追求最多组件，而追求最小但足够的控制闭环。

9、怎样设计人机分工

与其抽象地争论“还要不要人”，我更愿意先把动作摊开，按影响范围、可逆性和不确定性逐项授权。

对希望“不要中途一直问”的个人或团队，应该建立常驻规则：允许读取哪些目录和系统，允许使用哪些工具，什么金额或影响范围以内可自动处理，何时必须暂停；再要求任务结束时集中报告所有特殊处理、绕行方案、失败重试和未验证假设。这样既减少打断，也保留责任链。

对开发团队来说，继续雕琢提示词的边际收益很快会下降。更耐用的投入是让环境对 Agent 可读：把知识放进版本化文档，把架构边界变成可执行检查，把 UI、日志、指标和 trace 暴露给智能体，再把重复反馈写成测试。OpenAI 的 Harness Engineering 实践也指向同一个结论：环境工程会直接决定 Agent 吞吐量。

事实口径优先使用 OpenAI 当前官方手册与产品文档。进一步阅读：ChatGPT Agent System Card、Agents SDK、Harness Engineering、Symphony。

10、怎样证明系统可靠

Agent 的演示很容易成功：挑一个顺利样本，录下完成过程即可。生产系统更难，因为它必须在网页改版、工具超时、权限不足、数据冲突和任务中断时仍然给出可解释结果。可靠性不能用“看起来很聪明”衡量，而要用任务级指标和失败分布衡量。

多一步工作流，可靠性可能乘法下降

如果一条流程有 8 个必须成功的步骤，并且每一步独立成功率都是 98%，端到端一次通过率并不是 98%，而约为 0.98⁸ = 85.1%。真实系统里的错误还会相关，结果可能更差。这解释了为什么单工具演示很顺，长任务却容易在中途失败。

提升可靠性的重点也因此不是盲目增加重试。应先减少不必要步骤，为有副作用的动作加入幂等键，为长流程保存检查点，并区分可重试故障与逻辑错误。若错误来自目标理解偏差，连续执行三次只会更稳定地得到错误结果。

单位成功成本必须包含失败

更诚实的成本口径是：单位成功成本 = 全部模型、工具、人工复核和失败重试成本 ÷ 合格交付数量。如果便宜模型把调用成本降低一半，却让返工率翻倍，总成本未必下降；如果多 Agent 提高了覆盖面，却引入协调和验证开销，也要由任务通过率证明价值。

建立失败样本库，而不是只收藏最佳案例

每次事故都应归因到一层：目标不清、上下文缺失、工具异常、权限错误、验证不足或模型判断失败。修复也要落到对应层：补任务契约、改检索、增加幂等键、收紧权限、添加测试，而不是笼统地“换更强模型”。

评测必须贴近真实分布

如果系统 80% 的工作是修改已有文件，就不能只评测从零生成；如果高风险动作很少见，却后果巨大，就要单独做红队和故障注入。对可恢复任务，还应主动制造断网、超时、重复回调与状态过期，验证系统是否会安全停止、恢复或回滚。

可靠 Harness 的标志不是从不失败，而是失败能被看见、限制、解释，并沉淀为下一次不会重复的系统能力。