Agent Harness 设计指南

Agent Harness 设计指南：Coding Agent 实践

一个 Agent 由两部分组成：模型，以及模型之外的一切——Harness。本文从一句最简单的对话出发，拆解 Agent 从代码到 next token 的完整链路，再依次讨论 Context、Memory、Long-Horizon、Multi-Agent 四个方向的设计取舍，最后讨论如何通过评测与生产反馈让 Harness 和模型持续进步。

全文围绕三个问题展开：

问题	内容
机制是什么？	从 Agent 代码到 next token，一次本地文件查询如何完成
设计怎么选？	Context、Memory、Long-Horizon、Multi-Agent
如何持续改进？	Harness 拓展场景，场景反馈推动模型进步

三个问题层层递进：先看清机制，否则设计决策只能凭感觉；再基于机制做出取舍；最后用评测判断改得对不对。

---

核心观点

1. Agent = Model + Harness。 模型只做一件事：根据已有内容预测 next token。工具执行、上下文组织、状态管理、调度与评测，模型之外的一切都是 Harness。
2. 能力在模型，Harness 负责释放与对齐。 Harness 不创造智能，它决定模型的能力能发挥出多少，以及是否用在正确的方向上。
3. Context Engineering 是 Harness 的核心工作。 每次生成前，提供刚好足以支撑下一步行动的上下文：能力按需加载，上下文 append-only 以命中 prefix cache，窗口吃紧时由模型主动压缩。
4. 记忆走”简单架构 + 依赖模型进步”的路线。 目录树 + Markdown + BM25/grep，画像常驻、经验渐进加载；评测的是带记忆的 Agent 在真实任务上的成功率与 token 消耗，而不只是记忆问答分数。
5. 长程任务靠两个支点： Harness 工程的稳定性，以及长时间的目标保持（目标压缩 + 状态 offload 到磁盘）。
6. Multi-Agent 的瓶颈在模型的协作能力， Harness 负责提供状态、消息与交接接口。
7. 持续改进是一个闭环： 生产执行 → Harness 验证与演进 → 模型能力内化 → 更强模型与新场景。Harness 改进先回到生产，可迁移的能力再通过训练进入模型。

---

一、机制：一句对话背后的完整链路

1.1 从一个问题开始

用户在 Coding Agent 输入框里问：「当前本地有什么文件？」

完成这句话需要三样东西：

• 任务：用户用自然语言描述要完成的目标。
• 运行环境：Agent 还需要工作目录与可用权限等信息。
• 执行过程：模型决定下一步，Harness 负责工具执行。

选这个问题做例子，是因为模型自己无法回答——它不知道用户磁盘上有什么，答案必须来自执行环境。这恰好能把”模型做什么、Harness 做什么”的分工完整暴露出来。

1.2 完整执行链路

这里的「本地」指 Agent 当前工作目录，任务是列出第一层文件与子目录。

Agent 进程：  准备 messages 与工具定义  →  HTTP 请求
                                              ↓
推理服务：    解码与解析  ←  LLM 生成  ←  Chat template
                 ↓
Agent 续做：  执行 list_files  →  结果回写历史  →  再请求与回答

一句简单的问答，实际经历了两次完整的模型请求：第一次模型输出”我要调用 list_files”，Agent 执行后把结果写回历史；第二次模型才基于真实结果生成回答。链路从 Agent 进程出发，经过推理服务，再回到 Agent 进程——这就是 Agent Loop 的最小形态。

LLM 预测 next token；文件名来自执行环境。

1.3 构造请求：messages 与 tools

Agent 发出的是一个标准的 Chat Completions 请求：

POST /v1/chat/completions

{
  "model": "demo-model",
  "messages": [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "当前本地有什么文件？"}
  ],
  "tools": [{"type": "function", "function": {
    "name": "list_files",
    "description": "列出当前目录第一层条目",
    "parameters": {
      "type": "object",
      "properties": {"path": {"type": "string", "enum": ["."]}},
      "required": ["path"]
    }
  }}]
}

• model：调用哪个模型
• messages：系统提示词、用户问题
• tools：可调用的工具与参数约定

其中 tools 里每个字段的含义：

字段	含义
type / function	function 表示函数工具；function 对象描述调用约定
name / description	工具名称与用途
parameters / properties	参数结构为 object；properties 中的 path 是字符串
enum / required	enum：只允许 path=”.”；required：必须传入 path

请求中只带声明，真正的 list_files 函数保留在 Agent 进程里。

tools 本质上是写给模型看的说明书，而不是可执行代码。description 写得好不好，直接影响模型能否在正确的时机选中这个工具；enum、required 这类约束则在格式层面收窄模型的输出空间。工具的实现、权限与副作用都留在 Agent 侧，由 Harness 掌控。

1.4 Chat template：请求如何变成模型输入

结构化的 JSON 请求，到了推理服务会被 chat template 转换成模型真正看到的输入。下面是一个精简的教学模板，保留了同一份消息和工具定义：

<|im_start|>system
You are a helpful assistant.
# Tools
<tools>
{"type":"function","function":{
  "name":"list_files",
  "description":"列出当前目录第一层条目",
  "parameters":{"type":"object",
    "properties":{"path":{"type":"string","enum":["."]}},
    "required":["path"]}}}
</tools>
Use <tool_call> with name and arguments for tool calls.
<|im_end|>
<|im_start|>user
当前本地有什么文件？ <|im_end|>
<|im_start|>assistant

这段输入由三部分组成：

• System：角色与行为
• Tools：工具定义与调用格式
• User：这一轮的问题

拆开来看：

• 消息正文保持一致：还是同一条 system 提示词、同一个用户问题。
• 模板补上结构：角色边界、工具定义与调用格式，一起组成模型输入。
• assistant 是生成起点：输入到这里结束，模型从这里开始续写。

文本被编码成 token，模型接着预测下一个词或片段。

也就是说，模型看到的不是”消息列表”，而是一串被拍平、带特殊标记的 token 序列。这一点是后面 Prefix Cache 设计的基础：缓存复用的是这串序列的共同开头，任何对前缀的改动都会让缓存失效。

1.5 模型生成 tool call，推理服务解析

模型从 <|im_start|>assistant 开始续写。它没有直接回答，而是按 system 中约定的格式输出一次工具调用：

<|im_start|>assistant
<tool_call>
{"name": "list_files", "arguments": {"path": "."}}
</tool_call><|im_end|>

• 模型只产出文本：它”决定”调用工具，本质上仍是逐 token 预测出符合约定格式的片段。
• 参数受 schema 约束：enum: ["."] 让 path 只能是 .，减少模型自由发挥的空间。
• 模型不知道文件名：此时它还没有看到任何真实文件。

推理服务把 token 解码成文本，识别出 <tool_call> 标记，再解析成结构化的 tool_calls 返回给 Agent：

{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "id": "call_001",
        "type": "function",
        "function": {"name": "list_files", "arguments": "{\"path\": \".\"}"}
      }]
    },
    "finish_reason": "tool_calls"
  }]
}

• **finish_reason: tool_calls**：告诉 Agent 这一轮还没结束，需要执行工具后再请求。
• 解析可能失败：格式不合法、工具名不存在、参数不符合 schema，都要由 Harness 校验并处理——重试，或者把错误回写给模型。

1.6 执行工具、回写结果、生成回答

Agent 进程根据 name 分派到本地真正的 list_files 函数，在工作目录、权限与沙箱的约束下执行，然后把调用和结果都追加到 messages：

"messages": [
  {"role": "system", "content": "You are a helpful assistant."},
  {"role": "user", "content": "当前本地有什么文件？"},
  {"role": "assistant", "tool_calls": [{"id": "call_001", "function": {"name": "list_files", "arguments": "{\"path\": \".\"}"}}]},
  {"role": "tool", "tool_call_id": "call_001", "content": "[]"}
]

• 执行在 Agent 侧：模型提出调用，Harness 负责真正执行、权限检查与超时控制。
• tool_call_id 对应调用与结果：多个工具并行时靠它配对。
• 再次请求：带着完整历史，重新走一遍 chat template → LLM 生成。

最后一步：

追加 tool 结果  →  LLM 再次生成  →  assistant 回答

模型给出的回答类似：

当前工作区 /workspace/ 是空的——没有任何文件或子目录（包括隐藏文件也没有）。这是一个刚创建的新工作区，如果你想在已有项目目录里操作，告诉我路径即可……

LLM 继续生成 assistant 消息，由 Harness 将 content 展示给用户。

注意回答里”刚创建的新工作区””告诉我路径”这类内容：模型在真实结果（空目录）的基础上做了推断和引导。事实来自工具，表达与判断来自模型，两者各司其职。

1.7 Model 之外，都是 Harness

把这条链路抽象出来，中心是 Model：预测 next token，周围是六类 Harness 职责：

职责	内容	职责	内容
输入组织	Prompt、模板、Skills 与检索	沙箱与环境	目录、进程、网络与权限
参数解析	名称、参数与格式校验	会话与状态	历史、压缩、检查点与恢复
工具与执行	分派、MCP 与结果回写	调度与观测	重试、停止、预算与评测

回看前面的链路，每一步都能对号入座：准备 messages 是输入组织；解析 tool_call 是参数解析；执行 list_files 是工具与执行，同时受沙箱与环境约束；结果回写是会话与状态；循环何时停止由调度与观测决定。

能力在模型，Harness 负责释放与对齐。

• 释放：模型本来有能力，但没有工具、没有上下文就发挥不出来。
• 对齐：模型的输出要落在用户的真实目标、权限边界和成本预算之内。

---

二、Context Engineering

2.1 目标：为每次生成准备好前置内容

LLM 根据已有内容，预测下一个 token。

我们能做的，就是在每次生成前，提供足以支持下一步行动的上下文。

• 目标与约束，告诉它要做什么；
• 事实与工具结果，支撑它判断；
• 工具和技能说明，帮助它决定下一步怎么做。

既然模型只看”已有内容”，Harness 能施加影响的唯一入口就是上下文。Context Engineering 的目标不是塞得越多越好，而是足以支持下一步行动——缺了会做错，多了会稀释注意力、抬高成本、破坏缓存。本章后面的按需加载、Prefix Cache、上下文压缩，都围绕”刚好足够”展开。

2.2 能力体系：Tools、MCP、Skills 与插件

Coding Agent 对外提供三类能力入口：

• 子 Agent / 插件：围绕领域任务，组合角色与相关能力。
• 技能：提供可复用的做事方法与流程。
• 连接器：接入外部工具、资源与服务。

Harness 要做的，是把这些产品能力组织成模型可用的上下文。它们与底层机制的对应关系如下：

职责	机制 / 产品对应	怎么发挥作用
执行动作	Tools / 内置工具	如第一章的文件读取，Agent 分派并执行调用
接入外部能力	MCP / 连接器	连接外部工具、资源与服务，接入可调用能力
提供做事方法	Skills / 技能	组织流程、知识与约束，默认注入部分常用技能
组织领域能力	插件包 / 子 Agent	组合提示词替换、Skills、MCP 与 Commands

内置工具提供基础动作，连接器接入外部能力；技能与子 Agent 帮助 Agent 按领域方法完成工作。

这四类能力是逐层组合的关系：Tools 是原子动作；MCP 把外部系统也变成 Tools；Skills 告诉模型用这些动作按什么流程做事；插件包 / 子 Agent 再把提示词、Skills、MCP、Commands 打包成面向某个领域的完整能力。无论哪一层，最终都要变成上下文里的文字才能生效。

2.3 按需加载：Deferred Tools 与 Deferred Skills

用户可以不断添加 tools 和 skills。如果每一轮都把全部工具 schema 和技能正文塞进上下文，会带来一连串问题：

问题	表现
Token 成本	几十个工具 + 多个技能正文，每轮固定开销可达数万 token
注意力稀释	与当前任务无关的说明挤占上下文，模型更容易跑偏
选择错误	相似工具越多，选错工具或参数的概率越高
缓存失效	用户增删能力会改动 system 前缀，prefix cache 无法复用

能力可以无限增长，但每一轮的上下文必须有限且相关。 解决办法是让完整内容按任务需要加载：

当前任务  →  内置发现入口  →  模型选择能力  →  加载并使用

• Deferred Tools：候选工具先保留在能力库中；模型选中后，再注入所需工具 schema。
• Deferred Skills：技能正文与资源先保留在库中；通过索引或搜索定位后，再按需读取。

默认保留基础能力与发现入口，让模型决定这一轮要加载什么。

思路是目录常驻、正文按需：上下文里只放能力的名字、简介和一个发现入口（如搜索工具），把”这一轮需要什么”的判断交给模型。后面 Memory V2 的”画像常驻、经验渐进加载”是同一种设计哲学——相信模型的检索与判断能力，让系统随模型变强而变强。

2.4 Prefix Cache：按 append-only 方式组织上下文

原则是：system prompt 保持不变，已有消息不改写，环境变化只追加。

system:  You are a helpful assistant.
user[0]: 初始环境
  cwd=/workspace
  time=09:00, os=macOS
user[1]: 当前本地有什么文件？
assistant / tool: 调用与结果
user[n]: 环境变化提醒
  cwd=/workspace/src, time=09:10

• 初始环境：作为第一条 user 消息注入，包含当前目录、时间、操作系统等环境信息。
• 环境变化：追加新的 user 消息作为提醒，保留之前已经形成的前缀。

回到 chat template：缓存复用的是实际输入序列的共同开头。

这里有一个反直觉的设计点：时间、cwd 这类会变的信息不放进 system prompt。 如果放进去，时间或目录一变就会改写序列开头，后面所有 token 的缓存全部失效。把它们作为 user 消息注入、变化时追加提醒，前缀就能一直保持稳定。Agent 每轮都要带着完整历史重新请求，前缀缓存命中率直接决定了长对话的成本和首 token 延迟。

2.5 上下文压缩：主动发起，模型选择保留

正在落地的方案是”主动压缩 + Jev 选择压缩”：

窗口压力约 50%~80%  →  自动注入 token usage，模型可调用 compact  →  Jev 选择保留内容，继续任务

• Jev 决定保留什么：压缩时，由 Jev 模型选择哪些上下文需要保留，供后续推理继续使用。
• 同时计算 prefix cache 的代价：减少 input token 带来收益，但删除历史也会损失部分前缀缓存；当压缩的综合收益高于继续保留时，才执行压缩。

与”窗口满了被动截断”相比，有两个变化：

1. 时机前移、由模型发起。 在窗口用到 50%~80% 时就把 token 用量告诉模型，让它在任务的合适节点（比如完成一个子任务后）自己调用 compact，而不是在关键步骤中途被打断。
2. 压缩是一笔账。 压缩省下后续每轮的 input token，但会打掉已有的前缀缓存，只有综合收益为正时才值得压缩。这与 append-only 原则基于同一套成本模型。

---

三、Long-term Memory

3.1 记忆为什么难

记忆是一个没有被充分定义的问题：

• 用户期待不同。 有人希望记住喜好与偏好，有人期待 Agent 积累经验、越用越好。
• 全流程都有不确定性。 LLM 生成 → LLM 整理 → LLM 使用，LLM 本身是不确定的，多次判断让不确定性沿链路叠加，整个记忆系统更难保持确定性。
• 分类难以保证隔离。 银行卡密码记住之后，何时用、给谁看？LLM 的分类结果，不能直接充当隔离机制。

目标：让 Agent 越用越好，同时守住作用范围与读取边界。

这对应做记忆前必须想清楚的三件事：

• 记什么：偏好和经验是两类不同的需求，分别对应后面的 V1 和 V2。
• 可靠性：写入、整理、读取每一步都是 LLM 判断，误差会逐级放大，所以架构要尽量简单、可检查。
• 安全边界：敏感信息的隔离不能依赖”让 LLM 判断这是不是敏感信息”，必须有确定性的机制兜底。

3.2 从 V1 到 V2：演进与技术判断

维度	Memory V1	Memory V2
主要定位	共享用户画像和偏好习惯	让 Agent 在后续工作中复用经验
组织方式	类似 chatbot 的轻量记忆	目录索引 + Markdown 文件
使用方式	容量较小，记住少量信息	渐进加载，召回与存储两个工具
目前阶段	第一代已完成	已开始内部灰度，持续优化工作任务

V1 解决可迁移的用户画像和近期事项，V2 围绕「越用越好」展开。

技术路线的演进过程：

时间	事件
2025 年：检索增强的经验	原始记录切片 + embedding 是强基线。代码 Agent 的 AST + embedding 提升了大仓库理解。
2025 年底：模型搜索能力增强	模型更善于 grep / glob / regex，小仓库的检索优势缩小。CodeWiki 与 Skills 带来目录树、渐进加载的启发。
产品初期：先完成 V1	用约一个月先完成轻量 chatbot memory，到 2026 年 3–4 月，第一代基本完成。
2026 年 5 月：V2 首版	以目录树、Markdown 和 BM25 / grep 实现简单架构，尽量依靠模型能力，让记忆随模型进步。

判断：高层记忆起始规模较小，先用简单文本搜索就足够好。

路线转向来自代码场景的经验：当模型自己就很会用 grep / glob 搜索时，在小规模语料上额外维护一套 embedding 检索，收益在缩小，复杂度却不变。记忆的规模在早期远小于代码仓库，所以选择目录树 + Markdown + 文本搜索——没有向量库依赖，人可读可改，还会随着模型搜索能力提升自动变好。

3.3 Memory V2：常驻画像与按需加载的经验

目录按「领域 / 主题 / entry」逐层展开，用户画像等信息常驻上下文。下面是两条简化脱敏后的实际记忆：

• 用户偏好：架构文档先给高层总览，再逐步展开实现细节。
• 可复用经验：keywords: ESM, node_modules——临时脚本放在项目目录内，避免依赖解析失败。

对模型只暴露两个工具：

• 召回（关键词）：输入关键词，检索相关记忆。
• 存储（LLM 更新文件）：由 LLM 整理新增信息，更新文件正文与 metadata。

画像等常驻，其余内容按目录渐进加载。

两条示例对应两类需求：”架构文档先给总览”是偏好，每次都该遵守，所以常驻；”临时脚本放项目目录内”是经验，只在相关任务中有用，所以带 keywords、按需召回。什么时候存、存什么、什么时候查，都交给模型自主判断。

3.4 评测：从记忆问答到真实任务

早期评测与技术取舍。 在 LongMemEval 上的内部评测：

版本	得分
2026 年 5 月 V2 首版	85.3%
加入 embedding 的探索版本	95.2%

• 普通文件与 SSD 降低了架构依赖。Dreaming 的启发是提炼经验、减少冗余。
• 目录树与渐进加载会继续受益于模型能力的提升。

更高分是一种可能；产品目标仍是简单、可扩展、越用越好。

加入 embedding 能把分数提高约 10 个百分点，但团队没有因此切换方案——取舍的维度不只是榜单分数：普通文件方案没有额外的基础设施依赖、更易扩展，而且能吃到模型进步的红利。Dreaming 的思路（离线整理、提炼经验、去除冗余）则被吸收为提升记忆质量的方向。

在真实工作场景中评测。 传统问答设置没有覆盖完整的自主触发过程：记忆问答主要看能否答对，没有覆盖主动存储、主动查询的触发。因此要在内部 Bench 等真实工作场景中，实测带记忆能力的 Agent 的完整执行过程：

执行工作任务  →  主动存储经验  →  再次查询复用  →  验收质量与成本

统计存储与查询的触发率，比较同类任务的成功率和 token 消耗。评测对象是带记忆能力的 Agent，而不是单独的记忆组件。

LongMemEval 这类评测默认”记忆已经存好、问题已经抛出”，只考察能否答对。但在真实 Agent 里，最大的不确定性恰恰是模型会不会主动去存、会不会主动去查。

最终结果。 Memory V2 已开始内部灰度：

指标	结果	说明
LongMemEval	88.3%	保留客观对照
成功率提升	约 1～2%	内部 Bench 等工作负载
Token 消耗减少	约 15%	经验帮助后续工作减少开销

完成工作，沉淀经验，在之后的工作中表现得更好。

不引入 embedding，LongMemEval 也从首版的 85.3% 提升到 88.3%。在真实工作负载上，成功率提升幅度不大，但 token 消耗减少约 15% 更明显——经验让 Agent 少走弯路，这正是”越用越好”的体现。

---

四、Long-Horizon

4.1 长程任务的两个核心支点

• Harness 工程的稳定性：工具与执行环境可靠运行；状态保存与中断恢复；超时或进程退出后仍能接续。
• 长时间的目标保持：持续围绕交付、约束与验收推进；防止局部问题挤掉主目标；知道还差什么，避免过早收尾。

在步骤多、信息多、用户无法持续纠偏时，这两个支点尤其重要。

两个支点一个偏工程，一个偏模型行为：

• 稳定性是前提。 长任务可能跑几十分钟甚至几小时，任何一次工具挂起、进程崩溃都不能让任务从头再来，所以需要检查点与恢复。
• 目标保持是难点。 长任务里常见的失败不是”做不到”，而是被某个局部报错带偏、忘了最初的约束，或者没做完就宣布完成。

不同模型在这方面的风格差异明显。从使用观察看，GPT 相比 Claude 更擅长规划和长时间任务，Claude 更倾向于短平快地解决眼前问题。Harness 需要针对模型的特点补位。

4.2 目标压缩与状态 offload

• 高效的目标压缩：保留目标、约束、验收和下一步，让压缩后的上下文持续指向最终交付。
• 状态 offload 到磁盘：计划、进度与工具结果落盘，例如 plan.md、progress.md、outputs/。

Agent 以相对干净的上下文，不断完成局部任务，并回到同一目标。

• 压缩要有优先级。 最不能丢的是目标、约束、验收标准和下一步，过程细节可以丢。
• 磁盘是外部记忆。 上下文会被压缩，文件不会。计划和进度写成文件后，任何时候（包括压缩后、进程重启后）都能重新读回来，Agent 由此在”干净的上下文”与”不丢目标”之间取得平衡。

一个实用技巧：前期讨论已经很长时，先让 Agent 把结论和目标写成文件，再压缩上下文，然后再开始执行——避免带着一大段讨论历史去干活。

目标落成文件  →  先压缩上下文  →  再开始执行

---

五、Multi-Agent

5.1 环境感知与团队协作

Agent 团队就是一个典型的 Multi-Agent 场景：团长拆分任务，成员分工执行，再汇总交付。这对模型提出了两方面要求：

• 理解并发工作的环境：知道其他 Agent 的职责与状态；理解任务依赖和共享产物的变化；意识到自己的观察可能已经过时。
• 懂得如何一起工作：判断该委派、通知、等待还是接手；遇到分歧与冲突时调整配合；围绕共同目标形成结果。

单 Agent 的世界是静态的——自己不动，文件就不会变。多 Agent 并发时，”我刚读过的文件可能已经被别人改了”，模型需要具备观察可能过时的意识。委派、等待、接手、处理冲突这些协作判断，Harness 只能提供机制，真正做出正确判断仍依赖模型能力。

协作机制需要模型能力承接，仍需要模型侧进一步推动。

5.2 产品形态：Agent 团队

典型的 Coding 场景团队包括：软件开发团队（产品 / 架构 / 开发 / 测试）、MVP 快速原型团队、应用交付团队（从架构到上线）、云运维与迁移团队等。

团长分派与汇总，成员按职责推进任务。模型理解并发与协作，Harness 提供状态、消息与交接接口。

---

六、持续改进：评测与自进化

6.1 RSI：两条相互增强的演进路径

可组合的 Harness 提供变化空间，Memory 提供可复用的经验。RSI（Recursive Self-Improvement，递归自我改进）由此落到两条可工程化的路径上：

Evolution Engineering		自进化 Memory
搜索空间	Prompt、工具、上下文与工作流	积累	个人、Agent 与组织的任务经验
生成候选	配置、策略与代码都可以变化	抽取	成功方法、环境规则与失败恢复
评价选择	结果、过程、成本与约束	复用	按新任务召回，带入实际执行
回归保留	同任务、同预算验证，保留或回退	更新	用新结果修正或淘汰旧经验

• Evolution Engineering 把 Harness 本身当作可搜索、可优化的对象：Prompt、工具、上下文策略、工作流都是可变的”参数”，通过”生成候选 → 评价选择 → 回归验证”迭代。前提是 Harness 足够可组合，才有变化空间。
• 自进化 Memory 在运行时积累经验：抽取成功方法与失败恢复，在新任务中复用，再用新结果修正旧经验。

两条路径都依赖同一件事：可靠的评测。只有在同任务、同预算下对比，才能判断一个变化该保留还是回退。

6.2 生产反馈、Harness 演进与模型进步

成熟能力回到生产，执行结果再成为下一轮改进的证据，形成一个闭环：

生产执行 ──→ Harness 验证与演进
   ↑                  ↓
更强模型与新场景 ←── 模型能力内化

• 生产执行：Coding Agent 内核；产出任务轨迹、产物、成本与反馈。
• Harness 验证与演进：离线 Benchmark 筛选与回归；在线 A/B Test 验证真实收益。
• 模型能力内化：有效轨迹与失败案例形成训练信号，将可迁移的策略内化到模型。
• 更强模型与新场景：更长的自主执行、更复杂的任务；提高发现与验证改进的能力。

Harness 改进可先回到生产，可迁移能力再通过训练逐步进入模型。

Harness 和模型是两种速度不同的改进手段：

• Harness 改进快：改 prompt、改工具、改策略，验证后即可上线，直接服务用户。
• 模型改进慢但更通用：生产中积累的有效轨迹和失败案例成为训练数据，把被验证有效的策略内化到模型里。

模型变强后，又能支撑更长、更复杂的任务，拓展出新场景，产生新的反馈——这就是”如何持续改进”的答案。

---

总结

机制	Next token 生成与外部执行循环
设计	上下文、跨任务记忆、长程执行与并发协作
迭代	Harness 拓展场景，场景反馈推动模型进步

能力在模型，Harness 负责释放与对齐。

可落地的设计原则

领域	原则
工具	工具声明是写给模型的说明书；用 enum / required 收窄输出空间；实现与权限留在 Agent 侧
工具	事实来自执行环境，不依赖模型记忆
上下文	能力”目录常驻、正文按需”：Deferred Tools / Skills + 发现入口
上下文	system prompt 保持不变，环境信息作为 user 消息注入，变化只追加
上下文	压缩由模型在合适时机主动发起，并计入 prefix cache 的损失
记忆	偏好常驻、经验按需召回；先用目录树 + Markdown + 文本搜索
记忆	敏感信息隔离不能依赖 LLM 分类
记忆	评测带记忆的 Agent 整体：触发率、成功率、token 消耗
长程	目标 / 约束 / 验收 / 下一步优先保留；计划与进度落盘
长程	长讨论之后：目标落文件 → 压缩 → 再执行
多 Agent	Harness 提供状态、消息与交接接口；模型需意识到观察可能过时
迭代	同任务、同预算回归验证；离线 Benchmark + 在线 A/B