Agent Harness 只是换了名字的系统设计吗？
Agent harness 并不神秘：它大部分是系统设计在 LLM runtime 上的迁移。真正新的，是围绕非确定性输出和会退化的上下文窗口做工程。
本文为中文改写与评论，原文作者 Akshay Kokane，发布于 Level Up Coding / Medium，原文链接：What is Agent Harness? How it is different than System Design?。本文保留原文的核心观点和图示，并面向中文读者重新组织为一篇关于 agent harness 与传统系统设计关系的技术解读。
Agent harness 并不是从天上掉下来的新范式。它大部分是我们熟悉的系统设计：状态、权限、重试、日志、上下文、可观测性。真正新的地方，是这些设计现在包裹的是一个会幻觉、会漂移、会忘事的 LLM runtime。
这篇文章真正想反驳什么
原文的语气很直接：今天很多人把“agent harness”说得像一个全新发明，但老工程师一听就会觉得眼熟。所谓 harness，不就是在一个不可靠外部系统外面包一层工程结构吗？你要持久化状态，要校验输入，要管理权限，要处理超时和重试，要记录日志，要做审计。这些东西在后端系统里早就存在。
作者的有趣之处在于，他没有简单否定这个新名词。他的结论更细：90% 的 agent harness engineering 是传统系统设计迁移到了新对象上；但剩下 10% 的问题确实新，因为 LLM 不是普通 API、数据库或微服务。
这也是为什么这个词既让人烦，又值得认真对待。
什么是 Agent Harness？
从原文的定义看，agent harness 是围绕模型建立的一整套运行时结构。它不只是 prompt，也不只是某个框架，而是把模型接入真实应用时需要的执行层：上下文管理、权限、状态、工具调用、重试、人类介入、日志和审计。
原文把应用分成几层：
- 你的应用层：业务逻辑、产品体验、用户真正看到的部分。
- Harness Frameworks：LangChain、Microsoft Agent Framework、Google Agent Development Kit 等框架，它们提供 chain、agent、memory module 和 tool wrapper 等现成组件。
- Harness Runtime：真正执行 agent 的那层，包括 context、permissions、state、tool execution、retries、HITL 等。
- Model Layer：可替换的 LLM backend，它是非确定性的核心生成引擎。
如果不用框架，你就得自己把 runtime 层接起来；如果用框架，框架也只是帮你预组装了一部分 harness 组件。真正重要的不是用了哪个库，而是你有没有把这些边界设计清楚。
换了名字，但模式很老
作者说得很犀利：agent harness 的很多模式，本质上和传统系统设计一样。以前你封装数据库 driver、HTTP client、支付网关、消息队列，今天你封装 LLM。外层要做的事情看起来非常类似：超时、重试、幂等、校验、权限、观测、降级和审计。
真正改变的是被包裹的对象。数据库 driver 或 HTTP client 虽然会失败，但它们不会“想错目标”。LLM 的问题不是简单的 500 错误或 timeout，而是它可能发起一个语义上不该发起的工具调用，或者在第 40 轮对话之后忘记最初任务。
为什么还需要新名词？
原文给出三个原因：一个真诚，两个偏商业。
真诚的原因是：LLM 把非确定性放到了核心逻辑层。传统 retry-and-log 基础设施并不足够，因为模型可能返回格式正确但语义错误的结果。你不只是要校验输出格式，还要校验 intent，也就是模型“想做什么”是否被允许。
原文拿 Claude Code 的权限管线做例子：它不是只检查工具调用语法是否正确，而是要判断模型是否有权想要执行那个动作。这是 agent harness 和普通 API wrapper 的关键差别。
第一个犬儒原因是商业命名：公司需要平台、类别和市场。如果“agent harness”成为一个新品类，就有人可以卖 harness 平台、harness 框架、harness observability。
第二个犬儒原因是教育和话语权：很多进入 AI engineering 的人并不是系统工程师，他们需要新的词汇帮助理解。而谁先定义词汇，谁就更容易占领 SEO、会议议程和 mindshare。
真正新的是什么
原文认为，agent harness 里有两个部分并不能完全映射到旧系统设计。
第一，执行层的非确定性。传统 middleware 假设被封装的服务基本一致：同样输入通常得到同样输出，失败也有相对明确的模式。LLM 不一样。它可能每次都给出不完全相同的答案，也可能看似成功却偏离目标。这让测试、验证和权限设计都变复杂。
第二，上下文是一种会退化的一等资源。过去我们会管理内存、连接池、CPU、队列长度，但很少需要管理一种“越跑越容易语义漂移”的工作记忆。context window 不是普通缓存，也不是传统 GC。它有限、昂贵，而且会随着任务推进变得不可靠。
诚实的判断是：90% 的 agent harness engineering 是你已经知道的系统设计，应用到了新的底层对象上。剩下 10% 才是新东西：围绕非确定性输出和有限、会退化的上下文窗口进行设计。
这对工程师意味着什么
如果你已经做过真实后端系统，你并不是从零开始。你关于 state machine、retry、idempotency、observability、permissions、audit log 的直觉，直接可以迁移到 agent 系统里。
真正要补的不是“架构感”，而是把 prompt state 当作 program state，把 context window 当作最稀缺、最昂贵、最容易污染的资源。也就是说，不要把 prompt 当成一次性文本，而要把它当成会影响系统行为的状态变量。
这也是 Claude Code、Codex、OpenCode 这类 coding agent 都在做的事情：它们不是只靠模型变强，而是在模型外面建立工具、权限、上下文、计划、回滚和验证的结构。
给中文读者的总结
所以，agent harness 是不是“旧瓶装新酒”？某种程度上，是。它确实大量复用了传统系统设计的基本功。
但这个新瓶子也不是完全没意义。因为 LLM runtime 的失败方式不同：它会幻觉，会忘记，会语义漂移，会在格式正确的情况下做错事。传统工程经验依然有效，但需要被改造为面向非确定性和上下文退化的工程方法。
更实用的态度是：不要被新词吓到，也不要因为它像旧东西就轻视它。把 agent harness 看作“系统设计进入 LLM 时代后的新边界”会更准确。你熟悉的 90% 是优势；陌生的 10% 才是需要专门学习的地方。
