为什么同一个 LLM，换个 Agent 就像换了个人？用演员、导演和片场讲清 Harness 与 Runtime

如果把两个 Agent 的底层模型都换成同一个 LLM，它们会不会变成同一个产品？

不会。一个能在代码仓库里连续工作一小时，读取文件、修改代码、跑测试、遇到失败后恢复；另一个可能只能在聊天框里告诉你“建议检查日志”。演员是同一个，电影却完全不同。差异往往不在模型参数，而在模型周围的两层系统：Agent Harness 决定它怎样工作，Agent Runtime 决定这些工作如何真正发生。

先说明：这不是一套全行业统一的名词表

“LLM”相对明确，但 “agent harness” 和 “agent runtime” 在不同框架里会有重叠。有的 SDK 把循环、工具路由和状态管理都叫 runtime；有的产品又把 instructions、tools、memory、skills、loop 统称为 harness。

这篇文章不试图给所有库制定标准，而是给出一套便于设计、排障和分工的责任模型：

最短的区分是：模型做决定，Harness 塑造决定，Runtime 承担决定的后果。

第一层：LLM 是演员——有理解力和即兴能力，但它没有真正站在片场里

一个优秀演员可以读懂台词背后的意图，根据对手的反馈调整情绪，也能在剧本没写满时即兴发挥。LLM 做的事情很像：读取当前上下文，预测一个合适的下一步，可能是自然语言，也可能是结构化输出或一次工具调用。

但演员不会因为说出“把灯打开”，摄影棚的灯就物理亮起。类似地，LLM 生成：

{"tool": "read_file", "arguments": {"path": "src/app.py"}}

不等于文件已经被读取。它只是生成了一个动作提议。真正解析参数、检查权限、读取磁盘并把结果送回模型的是外部系统。

因此，单独的 LLM 通常不知道：

• 当前目录里真实有哪些文件；
• 上一次进程是否已经退出；
• 数据库写入是否成功；
• 某个凭证能访问哪些资源；
• 任务运行十分钟后，最初那台容器是否还活着。

它只能根据送入上下文的观察来判断。模型可以很强，却仍然会被错误的工具描述、残缺的日志和失真的环境反馈带偏。这就是为什么“换一个更强模型”经常有帮助，却不能替代 Agent 工程。

第二层：Agent Harness 是导演和编剧——把通用演员组织成一个具体角色

演员今天演外科医生，明天演律师，基础能力没有改变；改变的是剧本、导演方法、现场提示和可用道具。Agent Harness 的作用，就是把通用 LLM 组织成“代码 Agent”“客服 Agent”或“研究 Agent”。

一套 Harness 通常包含六类东西：

1. Instructions： 角色、目标、约束与完成标准，相当于剧本和导演阐释。
2. Tools： 模型能选择哪些动作，以及每个动作的名字、参数和说明，相当于道具表和可调度部门。
3. Context strategy： 哪些历史、文件、记忆和检索结果进入这一轮，相当于演员开拍前拿到的场景资料。
4. Agent loop： 什么时候继续观察—思考—行动，什么时候结束、交接或求助，相当于镜头调度与“再来一条”。
5. Skills / workflows： 针对特定任务渐进加载的方法和检查单，相当于分镜、动作指导和拍摄 SOP。
6. Guardrails and routing： 哪些请求拒绝，哪些动作升级审批，什么时候切换专家或确定性流程。

OpenAI 的 Agent 指南把单 Agent 描述为“模型在 instructions 和 tools 的支持下循环执行，直到满足退出条件”；Anthropic 则区分预定义路径的 workflow 与由模型动态决定过程和工具使用的 agent。两种表述都指向同一件事：Agent 不是多调用一次 LLM，而是围绕模型建立一个持续的决策循环。

Harness 设计会直接改变模型表现。工具叫 run_command 还是 delete_production_database，参数是否含糊，错误输出是否原样返回，长文档是一股脑塞入还是按需加载，都会影响模型下一步的判断。Anthropic 在 SWE-bench Agent 上甚至发现，修正工具的路径设计——强制使用绝对路径——比继续雕刻大 Prompt 更有效。

所以 Harness 不是“Prompt 的高级名字”。Prompt 只是剧本的一部分；Harness 还包括道具说明、镜头循环、上下文剪辑、技能加载和行为门控。

第三层：Agent Runtime 是片场——它不负责演好角色，但决定这场戏能不能安全拍完

导演可以要求“从楼顶跳下去”，真正决定演员从哪里跳、钢丝怎样固定、哪些区域封锁的是片场执行系统。Runtime 承担的正是这种现实责任。

它通常负责：

• 创建一次 run，分配进程、容器或沙箱；
• 保存消息、工作状态、产物和检查点；
• 执行工具调用，管理文件、网络、密钥和外部连接；
• 强制权限、审批、资源上限、超时和最大步数；
• 处理并发、队列、重试、取消、暂停与恢复；
• 把观察结果、错误和退出状态返回给 Agent loop；
• 记录 trace、token、延迟、工具副作用和审计事件。

LangGraph 对 runtime 的描述很有代表性：它负责长时、有状态 Agent 的 durable execution、streaming、human-in-the-loop 和 persistence；底层 Pregel runtime 又明确执行 Plan、Execution、Update 三个阶段。OpenAI 也强调将 Harness 与 compute 分开：状态外置以后，容器丢失并不必然让整次任务丢失，而且模型生成的代码可以与凭证隔离。

Runtime 最关键的一条原则是：安全边界必须由代码和基础设施强制执行，不能只写在 Prompt 里。

“不要删除生产数据”是一条 Harness 指令；数据库账号没有删除权限，才是 Runtime 边界。

“执行前先询问用户”是一条行为策略；审批事件没有返回 allow 就无法调用写工具，才是 Runtime 边界。

“失败后继续任务”是一条导演要求；状态持久化、幂等工具和检查点恢复，才让继续成为可能。

三者怎样完成一次任务：片场真正开机以后发生了什么

假设用户说：“修复这个仓库里失败的测试，并解释原因。”完整过程不是模型直接进入电脑，而是下面这个循环：

sequenceDiagram
    participant U as 用户
    participant R as Agent Runtime
    participant H as Agent Harness
    participant M as LLM
    U->>R: 提交任务
    R->>R: 创建 run / 工作区 / 权限上下文
    R->>H: 提供任务、状态与可用能力
    H->>M: 组装 instructions、上下文和 tools
    M-->>H: 提议 read_file / run_tests
    H-->>R: 形成下一步动作
    R->>R: 校验权限并执行工具
    R-->>H: 返回 stdout、错误、文件变化
    H->>M: 整理新 observation，进入下一轮
    M-->>H: 修改、验证或给出最终答复
    H-->>R: 满足退出条件
    R-->>U: 返回结果、产物与运行记录

这里有一条容易被忽略的往返边界：

只要观察与动作之间还会循环，模型就不只是“回答”；它正在参与一个有状态的控制系统。

为什么同一个 LLM，换个 Harness 就像换了一个人

假设模型完全相同，把它放进三套系统：

模型没有换，可见的信息、允许的动作、循环方式与现实边界换了。这四个变化足以让产品能力看起来像换了一个人。

反过来，强模型也救不了糟糕系统：导演给错剧本，片场把第三幕的道具送到第一幕，灯光断电后又没有场记，影帝同样拍不出完整电影。

出问题时应该改哪一层

Agent 失败以后，最浪费时间的做法是默认“模型不够聪明”。先看失败属于哪一层：

更像 LLM 问题

• 信息、工具和环境都正确，多次运行仍无法完成核心推理；
• 任务需要模型不具备的语言、视觉或专业能力；
• 输出约束清晰，模型仍持续产生结构性理解错误。

可尝试：换模型、调整 reasoning budget、微调或把难问题拆给专门模型。

更像 Harness 问题

• 选错工具，或根本不知道某个工具存在；
• 重复读取、过早结束、忘记验证；
• 长上下文塞满无关材料，真正约束被淹没；
• Prompt 里规则互相冲突，Skill 触发不稳定；
• 能完成任务，但过程昂贵、绕路且不可预测。

可尝试：改善 instructions、工具描述、上下文选择、Skills、路由和退出条件，并用轨迹评测验证行为是否改变。

更像 Runtime 问题

• 工具明明选对，却超时、权限失败或重复执行；
• 进程重启后状态丢失，长任务无法续跑；
• 并发任务互相污染文件或共享状态；
• 用户取消后后台仍在产生副作用；
• 日志只记录模型文本，没有真实工具结果和资源变化。

可尝试：修复隔离、状态机、幂等性、队列、检查点、权限、可观察性和资源治理。

一个实用判断法是：如果换模型仍以相同方式失败，先查 Harness 或 Runtime；如果只在真实执行时失败，优先查 Runtime；如果动作链稳定但关键判断仍错，再考虑模型能力。

三个常见误区

误区一：Agent 就是 LLM 加几个工具

工具只让模型“有动作可选”。没有状态、循环、退出条件、错误反馈与权限执行层，它更像带函数调用的聊天接口，而不是能持续工作的 Agent。

误区二：Runtime 只是部署服务器

Agent Runtime 不只是把 API 放进 Kubernetes。它需要管理一次任务从创建到结束的生命期，还要理解 tool call、observation、checkpoint、approval 与 cancellation。普通 Web 请求失败后重试可能没事；一个已经发过邮件或改过数据库的 Agent run 盲目重试，可能制造第二次副作用。

误区三：Prompt 里写了禁止事项，就等于有安全边界

Prompt 是给演员的要求，不是片场的安全绳。越接近资金、隐私、生产系统和外部消息，越应该让 Runtime 用最小权限、隔离、审批和可回滚动作把边界变成不可绕过的事实。

如果你正在搭一套 Agent，建议这样分工

可以把设计文档拆成三页：

1. Model contract： 输入输出模态、上下文窗口、工具调用格式、延迟、成本、已知能力边界。
2. Harness contract： 目标、指令、工具语义、上下文来源、Skills、循环、路由、退出与升级规则。
3. Runtime contract： 状态模型、隔离等级、权限、审批、超时、重试与幂等、检查点、审计、资源预算和恢复目标。

然后用一条端到端轨迹做验收：用户任务进入以后，哪段信息被送进模型？谁决定调用工具？谁阻止越权？工具失败怎样返回？任务重启从哪里恢复？最终产物和副作用由谁确认？

如果团队答不清这些问题，通常不是 Agent 不够“智能”，而是三层职责还揉在一起。

最后：不要只选演员，也要设计剧组

今天讨论 Agent 时，注意力很容易都落在模型排行榜上。模型当然重要：演员的理解力、表达力与临场判断，决定了系统能力的上限。

但真正进入生产以后，用户体验更多由三者共同决定：Harness 是否给了正确的剧本、工具和工作方法；Runtime 是否提供稳定的片场、清晰的权限和可靠的场记；LLM 是否能在这些条件下做出合适的下一步判断。

所以，Agent 不是一个模型，也不是一段 Prompt，更不是一台跑着 SDK 的服务器。

参考资料

1. OpenAI：The next evolution of the Agents SDK。关于 harness、原生 sandbox，以及 harness 与 compute 分离。
2. OpenAI：A practical guide to building agents。关于 Agent loop、instructions、tools、guardrails 和 orchestration。
3. Anthropic：Building effective agents。关于 workflow 与 agent 的区别、可组合模式及工具设计。
4. LangGraph overview。关于 harness、framework、runtime 的公开分层，以及 durable execution、streaming、HITL 和 persistence。
5. LangGraph runtime。关于 Pregel runtime 的 Plan、Execution、Update 执行模型。