芯耀
与非AI
189
原标题：Agent Harness的骨架正在标准化，真正值钱的是外层系统
最近看各种 Agent 工具，会有一个挺明显的感觉：
名字不一样，交互方式不一样，背后的模型也不一样，但工程骨架越来越像。
Claude Code、Codex、OpenCode、Hermes、Pydantic AI Harness，表面看都是不同产品；往下一拆，会发现它们都在回答同一个问题：
怎么把用户的一句话，变成一个真实可交付的结果？
用户说“帮我修这个 bug”“写一篇文章”“查一下这批数据异常”“把这个 PR review 掉”，这只是一个意图。Harness 要做的，是把这个意图变成任务、上下文、工具调用、权限控制、执行状态、结果验证和最终交付。
所以大多数 Agent Harness 的蓝图，可能 80% 都是相似的。
差异当然有，但更多发生在实现手法和产品取舍上，而不是底层问题本身。
先说清楚：Harness 是什么
Harness 这个词直译是“挽具”或“安全带”，在 Agent 工程里更像“工程外壳”。
模型本身只会根据输入生成输出。哪怕它支持 tool call，也不等于它天然就是一个可靠的 Agent 产品。
真正让模型能干活的，是包在它外面的那层系统：
- • 它知道有哪些工具可以用• 它知道什么权限能开，什么权限不能开• 它能把工具结果重新塞回上下文• 它能记住任务状态• 它能处理失败、重试和超时• 它能把结果展示给用户• 它能留下日志，方便你查它为什么跑偏
这层东西，就是 Harness。
如果说模型是发动机，Harness 更像底盘、油路、刹车、仪表盘和安全系统。没有 Harness，模型可以聊天；有了 Harness，它才开始像一个能接活的系统。
大多数 Harness 都绕不开这五层
不管具体工具叫什么，大部分 Agent Harness 都会长出五层结构。
1. Agent 层
这是最核心的 ReAct 循环。
1
LLM -> Tool -> LLM -> Tool -> Answer
模型先看用户意图和当前上下文，然后决定下一步：直接回答，还是调用工具。
如果调用工具，工具返回结果后，系统再把结果交回模型。模型继续判断下一步。如此循环，直到它认为可以给出最终答案。
模型可以是 Gemini、Claude、GPT，也可以是开源模型。模型不同，能力上限会不同，但这个模式不会变太多。
Agent 层解决的是“下一步做什么”。
它是整个系统里最像“大脑”的部分，但只靠这一层还不够。大脑要干活，还需要手、记忆、环境和约束。
2. Harness 层
这里才是大多数产品差异发生的地方。
Harness 层包在 Agent 外面，负责把“模型会思考”变成“系统能工作”。
常见组件包括：
- • Skills• Memory• Permissions• MCP• Subagents• Sandboxes• Context engineering
Skills 让 Agent 不用每次从零学习项目规则。Memory 让它能跨会话记住重要信息。Permissions 决定它能不能读文件、写文件、访问网络、执行命令。MCP 和插件负责连接外部工具。Subagents 让不同角色分工。Sandboxes 把危险操作关在笼子里。Context engineering 则决定每一轮到底把哪些信息交给模型。
很多人以为 Agent 产品的差异主要来自模型。实际用久了会发现，Harness 层的差异更直接。
同一个模型，被不同 Harness 包起来，体验会完全不一样。
一个 Harness 可能很激进，什么都敢改；另一个 Harness 可能很克制，每一步都要确认。一个记忆做得好，越用越顺；另一个上下文组装很差，聊几轮就忘。一个权限设计清楚，出错可控；另一个权限边界模糊，用起来总让人心里没底。
这就是 Harness 层的价值。
3. Runtime 层
Runtime 负责让任务跑得稳。
Agent 会判断下一步，Harness 会提供工具和约束，但真实任务经常不是一次调用就结束。
它可能要定时跑。可能会失败。可能要重试。可能要缓存中间结果。可能跑到一半需要人确认。可能要等外部系统返回结果后继续。
这些都属于 Runtime 层的问题。
常见工具包括 Prefect、Temporal、Kitaru 这类工作流或持久化执行系统。
如果 Agent 层问的是“下一步做什么”，Runtime 层问的是：
- • 什么时候跑？• 失败了要不要重试？• 重试几次？• 上次跑到哪里了？• 中间状态存在哪里？• 需要人介入时怎么暂停？• 人确认后怎么恢复？
这层东西在 demo 里经常被忽略，但一进生产就绕不开。
因为真实世界不会配合你的 Agent 一次成功。网络会断，API 会超时，权限会失败，用户会中途改需求，任务也可能跑到一半才发现信息不够。
没有 Runtime，Agent 更像一次性脚本。有了 Runtime，它才有机会成为可长期运行的系统。
4. Presentation 层
Presentation 是用户怎么接触这个 Harness。
入口可以很多：
- • TUI• Web• Mobile• Slack• Telegram
有意思的是，同一套 Harness 往往可以接多个入口。
你在命令行里对它说一句话，和在 Slack 里对它说一句话，背后可能走的是同一个 Agent、同一套权限、同一套 Runtime。
这也是为什么不要把“交互界面”和“Harness 能力”混在一起看。
一个工具看起来像命令行产品，不代表它背后的 Harness 只能跑在命令行里。一个工具先做成 Web，也不代表它的 Agent 能力天然更强。
Presentation 层解决的是“用户从哪里进来，以及结果怎么交回去”。
它重要，但它不是全部。
5. Observability 层
Agent 一旦开始多轮调用工具，调试就会变成系统问题。
传统程序出问题，你还能看日志、看堆栈、看指标。Agent 出问题更麻烦：它可能不是某一行代码错了，而是某一轮上下文错了、某个工具结果被误读了、某个权限没开、某个记忆污染了，或者模型在第七轮开始自信地跑偏。
所以 Observability 层必须跟上。
它通常要负责：
- • Tracing• Logging• Metrics• Evals
你需要知道每一轮模型看到了什么，调用了什么工具，工具返回了什么，token 花在哪里，哪一步开始偏离目标，最终结果有没有通过 eval。
没有这一层，Agent 跑得越自动，你越不知道它为什么错。
这也是很多 Agent 项目从 demo 走向生产时最痛的地方：不是模型不会回答，而是系统出了问题以后没人知道该从哪查。
骨架正在变成基础设施
把这五层放在一起看，会发现一个趋势：
Agent Harness 的骨架正在商品化。
大家最后都会收敛到差不多的结构：
- • Agent 层负责推理和工具调用• Harness 层负责记忆、权限、上下文和扩展• Runtime 层负责调度、重试和持久化• Presentation 层负责入口和交互• Observability 层负责调试和评估
不同产品会在细节上有差别，但大方向很难完全不同。
这有点像 Web 应用早期。最开始每个人都在争论框架，后来大家发现，路由、数据库、缓存、队列、监控、部署，迟早都要有。最后框架变成基础设施，真正的差异回到业务本身。
Agent Harness 也在走这条路。
这不是说 Harness 不重要。恰恰相反，基础设施很重要。但一旦基础设施越来越标准，单靠“我也有一个 Harness”就很难形成长期差异。
护城河会转移到哪里
如果 Harness 变成基础设施，真正值钱的东西会往外层转移。
我更看好这几类。
第一是业务逻辑。
同样是 Agent，客服、投研、代码审查、法务合同、供应链排产，背后的任务结构完全不同。谁更懂业务，谁就更知道该让 Agent 在哪里自动化，在哪里停下来问人。
第二是记忆体系。
Memory 不是把所有历史都塞进去。真正有价值的记忆，是知道什么该记、怎么分层、什么时候取、什么时候忘。记忆做不好，Agent 会失忆；记忆做太多，Agent 会被旧信息带偏。
第三是工作流。
很多业务不是一次问答，而是一串动作。提交、审批、验证、回滚、归档、复盘，每一步都有状态和责任边界。把这些工作流设计清楚，比单纯接一个大模型更难。
第四是上下文层。
Agent 的质量很大程度取决于它每一轮看到了什么。工具输出、文档片段、历史记录、错误日志、用户偏好，哪些该进上下文，哪些该压缩，哪些该丢掉，这是非常具体的工程活。
第五是领域知识。
通用模型懂很多，但不一定懂你的公司、你的客户、你的行业、你的代码库、你的发布流程。领域知识怎么结构化、怎么更新、怎么进入 Agent 决策，是产品价值的一部分。
为什么这件事值得普通开发者关心
因为这会影响我们怎么学习 Agent。
如果只盯着某一个工具，很容易被界面和命令迷住。今天学 Claude Code，明天学 Codex，后天又学 OpenCode，每个都像是新东西。
但如果按 Harness 五层去看，就会发现很多知识是可迁移的。
你在一个工具里理解了 ReAct loop，换到另一个工具仍然能用。你理解了权限和沙箱，就能判断一个 Agent 能不能放心交给它写文件。你理解了 Runtime，就会知道长任务为什么不能只靠一条 Prompt。你理解了 Observability，就不会在 Agent 跑偏时只会说“模型不行”。
这比追每个工具的新命令更重要。
工具会变，底层问题不会变。
一个简单判断
以后看一个 Agent 工具，可以用这五个问题快速拆。
它的 Agent 层怎么跑？是简单问答，还是能多轮调用工具？
它的 Harness 层有什么？有没有 Skills、Memory、权限、沙箱、MCP、子 Agent？
它的 Runtime 靠什么？能不能定时、重试、恢复、等待人工确认？
它的 Presentation 是什么？只能命令行，还是能接 Web、Slack、移动端？
它的 Observability 做到哪一步？能不能看到 trace、日志、指标和 eval？
这五个问题问完，一个工具大概处在什么水平，就能看得比较清楚。
结尾
Agent 产品还会继续变，但 Harness 的骨架已经越来越清晰。
Agent 层负责思考和调用工具，Harness 层负责包住它，Runtime 层负责让它稳定运行，Presentation 层负责把它交到用户手里，Observability 层负责让你看懂它为什么成功、为什么失败。
这套结构会越来越像基础设施。
真正的竞争会慢慢转向外层：你服务什么业务，积累什么记忆，跑什么工作流，怎么组织上下文，沉淀了多少领域知识。
模型很重要，Harness 也很重要。
但产品最后卖的，不是“我也有一个 Agent 底座”。
而是这个底座到底帮用户完成了什么事。
