Context 与 Harness 工程

1. 四层递进：Prompt → Context → Harness → Learning

大模型应用工程按"边界从小到大"分四层，后一层包含前一层：

💡 深入理解 · 三者是包含关系不是替代关系：Prompt 是 Context 的一部分，Context 是 Harness 的一部分。做 Harness 时里面一定含 Context 工程，Context 工程里又一定含 Prompt 工程。边界一层比一层大。

💡 深入理解 · 为什么会演进：
- Prompt 在单轮对话很好用，解决的是"表达"问题——模型不是不会，而是你没把话说明白。但撑不住复杂任务："分析公司财报"它没看过你的财报，"按公司规范写代码"它没看过你的规范。提示词擅长表达清楚，不擅长凭空补出模型不知道的知识。
- Context 因产品形态从聊天机器人变成 Agent（要多轮、调工具、写代码、传中间结果）而火。核心思想：模型未必知道，所以系统必须在合适的时机把正确的信息送进去。
- Harness 解决新问题：当模型开始连续行动，谁来监督它、约束它、在它跑偏时拉回来。前两代都停留在输入侧，Harness 管的是"整个运行系统"。

2. Agent = Model + Harness

除模型本身外，几乎所有决定 Agent 能否稳定交付的东西都属于 Harness——工具、上下文文件、记忆系统、评估机制、约束规则、恢复策略。换模型提升的是天花板，搭 Harness 提升的是落地能力。模型迭代放缓的今天，Harness 的提升空间比想象大得多。

3. Harness 六层组件

按"它在干啥"分三组六层：

输入侧（让模型看到正确的东西）
1. 上下文精细化：管"这一轮"发给模型的那坨上下文长啥样、怎么排布。三件事：① 把角色和目标钉死（跑偏根源是身份没说清）② 动态筛选不一次塞满（just-in-time retrieval，塞越多注意力越散）③ 结构化组织（固定规则/动态证据/中间结论分开放，防"自我污染"）。
2. 记忆与状态：管"上一轮的事怎么流到下一轮"。关键做法：状态外化到文件系统，别放上下文窗口里。

动作侧（让模型做出正确的事）
3. 工具系统：给哪些工具（只给真需要的）、什么时候用哪个、结果怎么喂回（30 条搜索结果先提炼再喂）。MCP 就是工具层标准化。
4. 执行编排：Agent 本质是个 for 循环（思考→行动→观察→再思考，即 ReAct）。给模型一条明确的工作轨道，让它知道"现在在哪一步、下一步干啥"。

校验侧（让模型知道做没做对 + 出错能爬起来）
5. 评估与观测：Eval 集（手写典型任务+标准答案，每次改完跑一遍对比成功率）+ Trace（看每步真实足迹：决策/调了哪个工具/返回/花多少 token，如 LangSmith/Langfuse）。
6. 约束与恢复：约束（硬编码到代码/linter，别写提示词里靠自觉）、校验（每步输出前后自动检查格式/白名单）、恢复（限流等待重试、发送失败落本地队列、token 快耗光立即停下保存进度）。

💡 深入理解 · 第一层 vs 第四层区别：第一层管"这一轮看到什么"（空间），第四层（记忆状态）管"上一轮怎么流到下一轮"（时间）。容易混。

4. Context Rot 上下文腐化与治理

上下文塞太满，模型出现上下文腐化（Context Rot）——记不住前面、前后矛盾、忽略最初规则，像被信息淹没抓不住重点。

Context Engineering 做三件事：召回（找最相关信息，RAG 管这一步）、压缩（摘要提炼省空间）、组装（按顺序排，重要的放后面，规避 Lost in Middle）。

❓ 常见追问 · Agent 跑久了上下文腐化怎么办？ → 三步：① 先做上下文压缩（摘要历史对话腾空间）② 压缩还不够（模型带"疲惫感"）就做 Context Reset（整个上下文窗口丢掉换干净的，状态从文件系统恢复）③ 关键是状态必须外化到文件而不是留窗口里。

❓ 常见追问 · 上下文压缩时大模型能力问题导致压缩质量差怎么办？→ ① 分层压缩，只压历史对话不压当前需求/规则等关键信息 ② 压缩用专门 prompt 约束保留要素（决策、约束、未完成项）③ 关键结论结构化落文件不依赖模型重述 ④ 压缩结果做校验，字段缺失回退到原文重试。

5. 记忆分层与状态外化（关键做法）

Agent 状态不应放上下文窗口，应外化到文件系统——维护进度日志、启动脚本、完整 git history 作"长期记忆介质"。下一轮换全新上下文窗口接手时，一读文件立刻知道"到哪步了"。

记忆必须分层存，三类生命周期完全不同，混一起就乱：
- 任务状态：写 progress 文件，任务完就归档。
- 会话中间结果：当轮用完就丢。
- 长期记忆：写常驻配置，每次调用都注入（如 CLAUDE.md、.cursorrules）。

6. Skills 渐进式披露

Skill = 操作经验——规定在什么场景、按什么顺序、组合使用哪些工具（工具可以是 MCP 插件或本地脚本）。可理解为大模型驱动的 workflow，比固定 workflow 灵活性更高。

核心机制 渐进式披露（Progressive Disclosure）：先只给模型看 skill 的元数据（精简信息，省 token），LLM 判断用哪个，真需要时才动态加载完整 skill（脚本+md）。

💡 深入理解 · 完整流程：① 用户发问给 CC ② CC 把问题+多个 skill 元数据一起发 LLM ③ LLM 判断执行哪个 ④ CC 把整个 skill 文件发 LLM ⑤ LLM 下达指令用什么脚本/工具 ⑥ CC 执行完把结果发 LLM ⑦ LLM 整理返回 ⑧ 返回用户。

❓ 常见追问 · Skills / MCP / Function 三者区别？→ Function Calling 是模型输出参数 JSON 本地执行（单个动作）；MCP 是工具接入的标准通信网关（跨平台复用）；Skills 是操作经验/流程编排，规定何时按何顺序组合用哪些工具（MCP 和脚本都可以是它调的工具）。层级：FC/MCP 是"工具"，Skill 是"用工具的方法论"。详见 → FunctionCalling · MCP

7. AGENTS.md/规则文件越写越长反而更糊涂

OpenAI 早期做 Codex 搞了巨大的 AGENTS.md 把所有规范塞进去，结果 Agent 更糊涂——上下文是稀缺资源，文件越长注意力越稀释。改法：从"百科全书"改成"目录页"，主文件只留约 100 行核心索引，详细内容拆子文档，按需加载。这就是渐进式披露。

❓ 常见追问 · 写 CLAUDE.md / Cursor Rules 的原则？ → 宁缺毋滥，少即是多。别百科全书化，有就赶紧拆成目录+子文档。

8. Agent 五个真实难题

1. 跑久了越走越偏？ → 重启开新终端（Context Reset），状态从文件恢复。
2. 自己给自己打分总偏乐观？ → 让干活的和验收的必须是不同的人（独立评估 Agent）。
3. 反复失败工程师该干啥？ → 别问模型能不能更努力，要问环境还缺什么。给 Agent 接 lint/单测/运行环境让它自己跑自己改（改造环境），而不是加提示词"请仔细检查"（求模型发挥）。
4. 规范文件越长越糊涂？ → 渐进式披露，改成目录页。
5. 代码越堆越烂（AI slop）？ → 把工程经验写成"黄金原则"沉进仓库，后台 Agent 按节奏自动扫描找偏离、自动开修复 PR。技术债像高息贷款，每天小额还一点，别攒着集中还。

9. claude code 相关

核心循环：本质就是 ReAct for 循环——读取用户输入+上下文 → LLM 决策（调工具/回答）→ 执行工具 → 结果回喂 → 再决策，直到完成。配合 CLAUDE.md 做长期记忆、Skills 做渐进式能力加载、状态外化到文件。

上下文治理：just-in-time 按需加载（不一次塞满）、压缩+Context Reset 应对腐化、状态外化到文件系统（git history/progress 文件）、CLAUDE.md 分层。

❓ 常见追问 · 两种 Harness 实现的关系 → Harness Engineering 是方法论（抽象层），Claude Code / Codex / 各家 Agent 产品是不同实现，掀开看内部六层组件惊人相似——因为"让 Agent 在真实世界稳定工作"这个命题天然把所有人推向同一方向收敛。

9b. Claude Code 实操配置

三层配置：项目级 .claude/（CLAUDE.md / commands/ / hooks/ / mcp.json / settings.json）、用户级 ~/.claude/（含 settings.local.json 不入版本控制）、会话级 /config。
Hooks（自动化，harness 落地）：事件类型 user-prompt-submit / tool-use(前) / after-tool-use(后) / permission-request。典型：after-tool-use 跑 bun run format || true（blocking:false）自动格式化，消灭 CI 报错。用途：格式化、权限检查、拦危险操作、日志。
MCP 配置：claude mcp add <名> <命令>，/mcp 验证，调用格式 /mcp__<服务器>__<提示>。常用 chrome-devtools / github / postgres / filesystem-mcp。
Subagents（并行子代理）：每个独立 200K 上下文互不争抢，.claude/agents.json 定义分工（code-reviewer/test-writer/doc-generator），并行提速。
三级扩展：自定义命令（.claude/commands/xxx.md → /xxx）< Skills（User/Plugin/Built-in 三类）< Plugins（Skills+命令+MCP+Subagent+Hooks 打包）。
实用命令：/compact（压缩释放 30-50% token）、/context（看 token 分布）、/rewind（回退代码+对话状态）、/cost、/review /security-review、/sandbox（隔离 bash）。
OpenClaw（自托管 Agent 网关）对比：把 IM 渠道接到 Agent 的 Gateway，记忆=工作区 Markdown 文件（MEMORY.md + memory_search 语义检索）、Cron 持久化调度、三道权限闸（入口 allowlist → 工具禁高风险 → Docker 沙箱）。是"状态外化到文件"的另一种典型实现。

10. 高频追问速答

❓ 常见追问 · Context Engineering 和 RAG 关系？ → RAG 是 Context Engineering 的一种具体实现技术，只解决"召回"这一步；Context 还包括压缩和组装。
❓ 常见追问 · Harness 和 Prompt/Context 关系？ → 包含关系，Harness 最大，是对"整个运行系统"的工程化。
❓ 常见追问 · 为什么 Agent 每步都会做，串起来就不会？ → 缺执行编排——它知道拉数据、知道写摘要，但不知道"先拉全量再逐个分析"，最后交付一堆半成品。要给它明确工作轨道。