Agent Harness 是 AI 时代的操作系统层

模型只是推理引擎，外部 Harness（Loop、Context、Memory、Tool 与 Verify）才是真正承载状态与确定性的操作系统。

模型本身还不足以构成 Agent，它需要 Harness 这一层操作系统才能持续工作。这是我读行业里关于 Agent 基础设施的讨论，尤其是《The Anatomy of an Agent Harness》这类梳理时，很认同的判断。

如果把大语言模型比作 CPU，围绕在模型外面的那一整层 harness，就相当于操作系统，涵盖了循环控制、工具调用、上下文调度、记忆检索、状态管理、评测与安全防护。裸 LLM 只能根据输入生成文本；而一个能在环境中持续工作的 Agent，需要反复经历「感知、决策、行动、接收反馈」的闭环。这个闭环不会从模型权重里自然长出来，必须依赖外部 harness 提供的运行时结构。

因此在思考 Agent 能力时，我认为单纯等待或更换更强的基础模型并不能解决所有问题。更关键的瓶颈往往在模型外部的系统设计：

工具定义是否明确、粒度是否可控
上下文是否按照优先级和层级进入 prompt
长期记忆能否在准确的时机被召回
文件系统是否能够稳定承载工作区的真实状态
评测系统能否如实反馈端到端任务的完成率
工具执行失败与权限异常能否被运行时捕获并纠偏
安全边界是否能在语义层把用户指令与外部数据严格隔离

从 Chatbot 到生产级 Harness

在关于 Agent 架构的讨论中，《The Anatomy of an Agent Harness》把围绕在模型周围的基础设施拆开、命名并做了规范化。

我的理解是，一个能够稳定工作的生产级 harness，至少要把十个核心构件调度起来：

Orchestration loop（编排循环）：驱动感知、决策、行动与反馈的执行循环。
Tools（工具集合）：把模型的语义决策翻译成对外部系统的真实操作（读写文件、执行命令、发起网络请求等）。
Memory（记忆管理）：跨对话轮次、跨任务沉淀关键事实，并在需要时检索。
Context management（上下文管理）：决定什么内容、在什么时机、以什么优先级进入活动上下文。
Prompt construction（提示词组装）：把系统角色、项目约束、任务资料与历史工具结果拼装为模型可理解的任务状态。
Output parsing（输出解析）：把模型的自然语言或格式化输出转化为确定的结构化调用或可验收产物。
State management（状态管理）：追踪当前环境、未完成任务、改动文件和运行时副作用。
Error handling（错误处理）：当工具报错、权限受限、上下文溢出或任务偏航时，提供恢复机制。
Eval / Observability（评测与观测）：不看回答写得是否流畅，只看目标是否真正被达成。
Guardrails（安全与防护）：限制高风险操作，建立权限审批机制。

在这十个构件里，我认为状态管理和错误处理比工具调用更容易被低估。模型一旦在某一步产生偏差，harness 就需要捕获异常，让系统回到安全状态；能不能做到这些，往往关系着任务最终能不能完成。

Loop 是 Harness 的执行节拍

在 harness 体系中，编排循环（orchestration loop）决定了系统的执行节奏。正如我在 Agent Loop 的核心是触发条件、停止条件和验证标准中梳理的，把模型放进循环，还不足以构成 harness。

要让 loop 可靠运行，我认为必须在契约层面明确三件事：

触发条件：什么时候启动？
停止条件：满足什么状态主动退出？
验证标准：通过什么客观证据确认任务已经达标？

把 loop 放到工作流中，它的价值在于把高频的手工操作转变成可稳定复现的 routine，例如同步文档、检查 CI 状态、拉取数据看板。每一个 routine 都应该用 checklist 或专门的规则文件约束验证标准，用定时任务约束触发时机，并用人工确认拦截高风险动作。如果缺少了停止条件与验证标准，单纯让模型循环执行，只会带来不必要的调用开销和状态混乱。

Markdown 是 Context 路由协议

我倾向于把 Markdown 用作上下文管理的系统级接口。如果只把它当作供人阅读的普通排版格式，就忽略了它在系统中的作用。详细的逻辑在 Markdown 是 Agent OS 的 context API 有完整展开。

在受控的 harness 中，我认为不同类型的 Markdown 文件应当承担清晰的上下文分层：

AGENTS.md：规范 Agent 在当前工作区内的行为边界与工程原则；
SKILL.md：定义特定类型任务的标准执行步骤与工具使用规范；
任务计划文档（Plan）：跟踪单次任务的分步进度与执行上下文；
知识库索引（Index）：提供系统可快速检索的目录指针；
原始资料存档（Source）：提供不被二次加工的底层事实与出处。

如果把所有 Markdown 资料不加区分地直接灌入模型上下文，很容易造成上下文污染：过期的笔记会干扰当前规则，冗长的背景资料会挤压工具输出的配额，而未消化的草稿甚至可能被模型误读为执行指令。因此，Harness 的核心职责就是在恰当的时机，将对应层级的文本送达活动上下文。

上下文压缩是状态 Checkpoint

在面对复杂长程任务时，上下文窗口迟早会被填满，模型不得不面临压缩（compaction）。

上下文管理要管「往里放什么」，也必须保障「丢掉逐字历史后如何恢复状态」。我赞同关于上下文压缩讨论中的这个观点：压缩机制必须把对话历史转化为可信的状态 checkpoint：

活动上下文：仅保留当前步骤最核心的目标、约束与刚执行完的工具反馈；
状态摘要：将已经达成的决策和中间结论提取为语义 checkpoint，避免在多次摘要后累积语义漂移；
缓存前缀（Prompt Cache）：保持静态规则与前置指令的稳定性，降低重复计算延迟；
持久化状态：将具体的文件修改、测试日志、Git commit 沉淀到工作区磁盘，而非依赖模型记忆。

上下文被压缩后，我认为 Harness 应当引导 Agent 重新读取磁盘中的真实状态和验证结果。模型残留的模糊记忆，不能替代这一步。

安全防线必须建立在上下文来源上

当 Agent 拥有了调用工具、读写本地文件和发起网络请求的能力，安全威胁的性质就发生了改变，防线不能再停留在模型是否拒答敏感词上。

现实中最棘手的风险来自于间接提示词注入（Indirect Prompt Injection）：

检索到的网页内容中嵌入了欺骗性指令；
外部发来的日历邀请、邮件或图片隐写中夹带了特定指令；
正在分析的外部代码或数据文件中包含了让 Agent 绕过权限检查的文本。

面对这类风险，我认为 Harness 必须在数据流入时严格区分上下文的信任等级：

用户指令：享有最高执行优先级；
工作区配置：作为不可动摇的行为准则；
外部输入与工具返回值：必须始终作为待处理的 Data（数据） 呈现，不能被解析为覆盖系统规则的 Instruction（指令）。

从个人工程到组织积累

《A frontier without an ecosystem is not stable》把 Harness 的逻辑放到了团队和企业层面。企业需要把人的判断、业务经验与规则，逐步沉淀为系统化的「Harness 资产」：私有知识库、经过验证的工具链、自动化的测试评测集，以及约束 Agent 执行的完整协议。仅仅购买某家模型的 API，还不足以构成这些核心数字化资产。

衡量个人的 AI 应用水平，我会看他能否为自己搭建起一套稳定的工程脚手架，把平时的踩坑与思考，转化成可复用的 context、可执行的 tools 以及客观的 eval 验证标准。单凭掌握了多么复杂的 prompt 技巧，还不足以说明这些能力。

我眼中的关键边界

根据这些架构讨论，我给 Harness 的设计划了五条边界：

坚持把 Markdown 当作机器接口：所有的索引、规约、流程说明，优先考虑能否被 Agent 结构化读取与执行。
不一次性全量塞入：保持活动上下文的干净，依赖目录索引和分层机制按需调取内容。
高频任务应当固化为流程：只要是需要多次重复的工作，就应当形成清晰的 checklist 或执行规范。
外部输入始终降级为纯数据：任何来自第三方页面、抓取结果或外部文件的内容，不直接作为控制指令执行。
验证机制先于生成能力：评价一个 Agent 是否合格，要检查它能否借助真实命令、测试和磁盘状态核对结果。文字生成得流畅，不能替代这些验证。