如果你符合下面任意一条，这篇是给你的：
这篇不是给“开发 AI 应用”的工程师写的。如果你要构建 AI 产品、做 RAG 系统、优化推理性能、设计 Agent 框架，这篇只是入门背景，不是深度指南。
全文围绕一个公式展开：
智能体（Agent）= 模型（Model）+ Harness（运行时工程层）+ 自主循环（Autonomous Loop）
这三个词分别对应三个问题：
三者合起来，才是 Agent。缺了模型，什么都不会生成；缺了 Harness，模型只是聊天窗口；缺了自主循环，Agent 就退化成一条固定工作流。
但这三样东西不是凭空出现的。它们各自解决什么问题、彼此怎么配合、在实际工作中怎么体现，就是全文的内容。
全书分四层：
| 层 | 回答的问题 | 核心内容 |
|---|---|---|
| 模型（Model） | 模型本身能做什么、不能做什么 | Token、上下文窗口、推理模型、幻觉、采样参数 |
| Harness（运行时工程） | 怎么让模型稳定干活 | 上下文、工具、记忆、编排、验证、约束 |
| 智能体（Agent） | 模型怎么自己决定下一步 | Agent 循环、任务拆解、多 Agent 协作、失败模式 |
| 产品（Product） | 人怎么用、团队怎么协作 | 工作流光谱、规范驱动、审查、治理 |
这四层是一条递进链。模型层是能力边界，Harness 层是工程基础设施，Agent 层是自主决策，产品层是人的工作流。理解这条链，你就知道每个新概念该放在哪里。
四层怎么区分？一个简单判据：
谁决定下一步？
这个判据贯穿全文。遇到一个新概念，问自己“谁决定下一步”，就知道它属于哪层。
举个例子。Function Calling 是什么层？模型输出调用意图，但真正执行的是 Harness，所以它属于 Harness 层，不属于模型层。再比如 Subagents：主 Agent 派生子 Agent，但编排逻辑由人/代码决定，所以它属于 Harness 的编排层。只有当模型自己决定“我要派一个子 Agent 去查这个信息”时，才是 Agent 层的行为。
第 3 章（Harness 层）是全篇最厚的一章，因为它是日常操作的核心。你每天用的功能——提示、上下文、规则文件、工具调用、记忆——大部分都在这一层。
每个概念只有一个主位，其他地方只做扩展联系。
比如“评估”的机制主位在 §3.5，基准与指标在 §6.4 展开，两处不重复。“安全”的防御机制主位在 §3.6.1 护栏，威胁形态在 §6.1 展开。“治理”的运行时机制主位在 §3.6.3，企业框架在 §6.7 展开。
这样做的好处是：你不会在四个地方看到同一个概念的四段不同解释，然后困惑“以哪为准”。
下面这些概念经常被搞混，建议先有个印象，读完第 3 章后回来再看一遍：
| 易混对 | 区别 |
|---|---|
| 规则 vs 规格 | 永久约束 vs 单次需求 |
| 上下文 vs 记忆 | 单次可见 vs 跨轮次持久 |
| 护栏 vs 钩子 | 约束边界 vs 触发动作 |
| 评估 vs 恢复 | 判断做对没有 vs 处理出错之后 |
| 意图工程 vs 规范工程 | 组织级 vs 企业级 |
| Agent 循环 vs 循环工程 | 智能体内部的决策循环 vs 设计围绕 Agent 的外部触发/停止/验证系统 |
如果你只想知道“现在该怎么用 AI 写代码”，可以跳过这一章，直接从第 2 章开始。
但如果你想理解“为什么会有 Harness 这个概念”，这一章是必要的。因为 Harness 不是凭空出现的，它是 AI 编程工程重心几次转移之后的产物。不理解这条演进线，你会觉得 Harness 只是又一堆新名词的堆砌。
这条演进线可以概括为五次叠加。每一次叠加，都是因为前一层解决不了新问题；每一层又叠加在前一层之上，不取代前一层：提示工程今天仍然有用，只是不够用了。
2022 年底 ChatGPT 发布，到 2023 年，大家关心的是同一个问题：怎么写提示词，让模型回答得更好？
这个阶段的核心技巧包括：
角色设定。“你是一个资深 Python 工程师”——这句话能让模型的回答更专业。它不是在假装，而是通过角色描述激活了模型训练数据中相关的模式。
Few-shot。给几个例子，让模型照着例子的格式回答。比如你想让模型输出特定格式的 JSON，与其描述格式，不如直接给两个示例。
思维链。“让我们一步步思考”——这句话能让模型在给出答案前先生成推理过程，显著提高复杂任务的准确率。它后来被内化为推理模型的训练目标，但在 2023 年，它只是一个提示技巧。
提示工程解决的是“怎么问”的问题。同样的模型，问法不同，答案质量差别很大。但它有一个天花板：它只关心措辞，不关心模型看到了什么信息。
你可以在提示词里写“请遵循项目的代码规范”，但模型不知道你的代码规范是什么，这句话就是空的。你可以写“参考已有的实现”，但模型看不到已有的实现，它只能猜。
提示工程的具体技法如今已融入上下文工程与工具描述（见 §3.1、§3.2），本文不为其单设主位。
2024 年，大家发现提示词写得再好，模型看不到代码库也没用。
上下文工程解决的是“给对信息”的问题。这个阶段出现了一批今天仍在使用的机制：RAG、仓库索引、@引用、规则文件（详见 §3.1）。
这个阶段的一个关键认知是：上下文不是静态模板，而是一个动态系统。
同一个任务，在不同的代码状态下，需要注入的上下文完全不同。你改一个函数，模型需要看到这个函数、它的调用方、它的测试、相关的类型定义。你加一个新功能，模型需要看到项目的目录结构、已有的类似实现、项目的依赖。
上下文工程要设计的，是这套动态系统。它不是“写一句更好的提示词”，而是“在正确的时刻，把正确的信息，以正确的格式，注入到模型的上下文中”。
从“怎么问”到“给它看什么”，这是第一次真正的认知升级。因为大家意识到：模型回答的质量，不取决于你问得多好，而取决于它看到了什么。
2025 年，Agent 开始自主行动，问题变成了：怎么让 Agent 知道组织想要什么？
提示工程解决“怎么问”，上下文工程解决“给什么信息”，但它们都没有回答“为什么做”。
一个 Agent 可以完美地完成一个任务，但这个任务可能不是组织真正想要的。你让它“优化这段代码”，它可能把可读性优化没了，换来一点性能提升，而组织可能更看重可读性。
意图工程（Intent Engineering）要做的，是把组织目标、价值观和权衡层级编码到 Agent 的基础设施中，回答“为什么做”（详见 §3.1.4）。规范工程（Specification Engineering）更进一步，把企业政策、质量标准、组织协议编码为机器可读的语料，支撑多 Agent 系统大规模自主运行（详见 §3.1.5）。
这两个概念目前还在早期，但方向已经清晰：Agent 越自主，越需要明确的意图和规范。你不能指望一个自主 Agent 自己猜出“这个项目优先考虑可维护性而非性能”。
2025 年下半年，大家意识到一个事实：模型能力不是瓶颈，运行时才是。
同一个模型，套上不同的 Harness，效果天差地别。一个裸模型只能生成文本；加上工具，它能读文件、跑测试、执行命令；加上记忆，它能跨轮次保持状态；加上编排，它能协调多个子任务；加上验证，它能自己发现错误并修正；加上约束，它不会闯祸。
这些加起来，就是 Harness，即围绕 LLM 建立的运行时工程系统。Harness 工程的核心问题是：怎么让模型稳定、可控、可验证地干活？这是第 3 章的全部内容，也是全文最厚的一章。
2026 年，最前沿的实践者不再手动提示 Agent，而是设计循环。
Boris Cherny（Claude Code 作者）2026 年 6 月说：“我不再提示 Claude 了。我有一直在跑的循环。是它们在提示 Claude，在决定该做什么。我的工作是写循环。”
循环工程的核心是：按计划或仓库事件触发 Agent 运行，在机器可检查的条件满足时停止；人不再每一轮都介入，而是设计好触发条件、停止条件、验证机制和升级路径（详见 §3.4.6）。
这不是说人不再参与，而是说人的参与从“每一步”变成了“设计循环”。你不再坐在电脑前一步步指挥 Agent，而是设计一套系统，让 Agent 在满足条件时自动运行、自动验证、自动停止，只在需要人决策时才升级给你。
除了上面五次叠加，还有两条并行演进线值得关注。
氛围编程 → 智能体工程
Vibe Coding 是 2025 年的流行词，强调用自然语言随性地驱动 AI 写代码。它的优点是快，缺点是质量不可控。Agentic Engineering 是 Karpathy 在 2026 年 2 月提出的进化版：99% 的时间不再直接写代码，而是在指挥智能体干活。区别在于：Vibe Coding 强调随性，Agentic Engineering 强调系统化编排和治理（详见 §5.7）。
软件开发生命周期 → 智能体交付生命周期
从 SDLC 向 ADLC 的演进，改变的是“谁在做”与“怎么做”。传统 SDLC 里，人写代码、人测试、人部署；ADLC 里，Agent 承担大部分执行工作，人的角色变成“意图建筑师”（设计目标和约束）与“监护人”（审查和兜底）。这个转变还在早期，但方向已经明确：工程师的核心能力正在从“写代码”转向“定义问题、设计约束、验证结果”。（ADLC 目前是成熟度 L2 的候诊概念，详见 §7.2。）
本章回答：模型本身能做什么、不能做什么、成本多少？
本章以 CLI 待办工具为例，仅在 2.2、2.5 涉及案例。
大语言模型（LLM） 是基于 Transformer 架构的神经网络。
要理解模型的能力和限制，你不需要会训练模型，但需要知道它大致是怎么造出来的。因为这决定了它为什么会有幻觉、为什么有知识截止、为什么同样的输入会给出不同的输出。
Transformer 和注意力机制
2017 年，Google 发表了一篇论文《Attention Is All You Need》，提出了 Transformer 架构。它的核心机制叫“注意力”——让模型在处理每个词时，能“看到”上下文里所有其他词，并计算它们之间的关联强度。
举个例子。当你读到“银行”这个词时，注意力机制会帮你判断：前面的“河”决定了这里的“银行”是河岸，还是前面的“存款”决定了它是金融机构。传统模型做不到这一点，它只能按顺序处理，看不到全局。Transformer 能同时看到所有词，并动态决定哪些词更重要。
这个机制是之后所有主流大模型的基础。GPT、Claude、Gemini、Llama，全部建立在 Transformer 之上。
预训练：从海量文本里学语言
预训练阶段做的事情很简单，但消耗巨大：给模型看海量文本，让它学会预测下一个词。
模型看到“今天天气真”，就要预测下一个词是“好”还是“差”。预测对了，参数微调；预测错了，参数往反方向调。这个过程重复数万亿次，模型逐渐学会了语法、事实、推理模式，甚至一些世界知识。
预训练产出的模型叫“基座模型”。它已经有很强的语言能力，但还不太听话：你问它问题，它可能会继续写下去，而不是回答你。因为它只学会了“预测下一个词”，还没学会“回答用户问题”。
后训练：从基座模型到对话助手
后训练阶段，用人类反馈调整模型的行为。常见方法包括：
后训练之后，模型变得更有用、更安全、更听话。它知道什么时候该回答、什么时候该拒绝、用什么格式回答。
你能调什么，不能调什么
理解这一点的关键是：模型的行为是训练出来的，不是你调出来的。
你能调的只有两样东西：
你不能调的是模型本身：它的知识、它的推理能力、它的偏好，都是训练时固定的。所以当模型表现不好时，先检查你给它的上下文和提示，而不是抱怨“模型不行”。
词元：模型眼里的文本
词元（Token） 是模型处理文本的最小单位。
模型不看“字”或“词”，它看 Token。一个 Token 可能是一个完整的词（如“hello”），也可能是词的一部分（如“un”+“happi”+“ness”），还可能是一个标点符号。
对于英文，一个 Token 大约等于 0.75 个单词。对于中文，一个汉字大约是 1 到 2 个 Token。所以“你好世界”大约是 4 到 8 个 Token。
为什么要知道 Token？ 因为模型的一切限制都跟 Token 挂钩。
比如 Claude 的上下文窗口是 200K Token，大约等于 15 万个中文字。超出这个限制，要么截断，要么分多次调用。GPT-5.4 支持 105 万 Token 上下文和 12.8 万 Token 输出，这意味着它能一次处理一整套中小型代码库。
分词（Tokenization） 是把文本切成 Token 的过程。不同的模型用不同的分词器，所以同一个文本在不同模型里的 Token 数可能不同。这会影响计费和上下文管理。
视觉输入
2026 年的主流模型支持直接输入截图、设计稿、甚至手绘草图。你截一张 UI 图，模型能识别出布局、组件、样式；你给一张手绘草图，标注了“这里是一个按钮，这里是一个列表”，模型也能理解。
这就是“多模态编程”的输入基础——“照着设计稿写页面”从手工翻译变成了自动生成（能力详见 §2.3，工作流详见 §5.8）。它也有局限：生成的代码可能不符合项目规范（因为模型不知道你的规范）；复杂的交互逻辑难以从静态图里推断；像素级的精确还原仍然需要人工调整。
中间信息丢失：标称窗口不等于有效窗口
这是一个非常重要的认知。
经典研究（Liu et al., 2023）发现，LLM 对长上下文中间位置的信息利用效率显著低于首尾。也就是说，你把 100 万 Token 塞进上下文窗口，模型对开头和结尾的信息记得最牢，中间的信息容易被忽略。这个现象叫 “Lost in the Middle”。
为什么？因为注意力机制虽然理论上能关注到所有位置，但实践中，首尾位置在训练时被更频繁地加权，模型学会了优先关注它们。
实际影响有多大？ 举个例子。你让 AI 写一个 CLI 待办工具，把 5000 行的项目代码全塞进去。它可能：
结果就是：它生成的代码跟现有逻辑对不上，因为你放在中间的那段关键代码，它根本没“看进去”。
实用建议：
2026 年的一些新模型（如 Gemini 2.5 Flash）通过改进注意力机制，已经明显改善了 Lost in the Middle 问题。但“标称窗口不等于有效窗口”这个认知，仍然适用于大多数模型。
推理模型 vs 标准模型
2024 年底开始，模型分成了两条路线：
标准模型：你问它问题，它直接生成答案。速度快、成本低、适合简单任务。
推理模型：你问它问题，它先生成一段“思考过程”，再给出答案。这个过程叫“测试时计算”——模型在回答前花更多算力思考。速度慢、成本高、适合复杂任务。
推理模型适合什么？
标准模型适合什么？
什么时候用推理模型？ 当任务需要“想清楚再动手”的时候。比如重构一个模块、设计一个数据结构、排查一个偶现的 bug。
什么时候用标准模型？ 当任务很直接的时候。比如补全一行代码、把 JSON 转成 YAML、解释一个函数的作用。
推理模型的成本结构和普通模型不同——大量 Token 花在内部思考上。举个例子：一个标准模型可能输入 1000 Token、输出 500 Token；同一个任务用推理模型，输入仍然是 1000 Token，但内部思考消耗 3000 Token，输出 500 Token，总消耗是标准模型的 3 到 4 倍。选型时要把这部分算进去。
模型家族
不同的模型有不同的专长，就像不同的工具适合不同的活：
2026 年的两个趋势
多模态编程模型成为主流。你可以直接给模型看设计稿、截图、甚至手绘草图，让它生成代码（机制见 §2.2）。
小语言模型（SLM） 在本地推理场景中角色日益重要。它们体积小、速度快、可以离线运行，适合隐私敏感或延迟敏感的场景。虽然能力不如大模型，但对于代码补全、格式转换等简单任务，已经够用。
温度：控制随机性，不是创造力
温度（Temperature） 控制生成时的随机性。
温度低（如 0.1），模型倾向于选择概率最高的词，输出更确定、更保守。温度高（如 1.0），模型会尝试低概率的词，输出更多样、更有“创意”。
但温度不是创造力开关。 温度调高，模型不会变得更聪明，只会变得更多样。
举个例子。你让模型写一个排序函数。温度 0.1 时，它可能每次都写快速排序。温度 1.0 时，它可能这次写快速排序，下次写归并排序，再下次写堆排序。它没有“更有创意”，只是随机性更高。
对于代码生成，建议用低温度（0 到 0.3），因为代码需要确定性，不需要创意。你不会希望同一个函数每次生成的结果都不一样。
Top-p：控制候选词范围
Top-p 控制候选词范围。Top-p 等于 0.9 意味着模型只从累积概率前 90% 的词里选。
它和温度配合使用，通常调一个就行。如果温度是 0.1，Top-p 设为 1.0（不限制），效果就是“在最高概率的几个词里选”。如果温度是 1.0，Top-p 设为 0.9，效果就是“在累积概率前 90% 的词里随机选”。
停止符：什么时候停
停止符（Stop Tokens） 是模型生成到这些标记时停止。
比如你可以设置 \n\n 作为停止符，让模型生成到空行就停；或者设置 </code> 作为停止符，让模型生成到代码块结束就停。停止符在工具调用和结构化输出中特别有用：你可以让模型生成到特定标记就停，然后 Harness 解析这个标记之后的内容。
惩罚项：控制重复
频率惩罚降低重复词的概率；存在惩罚鼓励模型谈论新话题。写代码时通常不需要调这两个参数，但在生成文档或对话时，如果模型反复说同一句话，可以适当调高频率惩罚。
推理努力：推理模型独有的调参维度
推理努力（Reasoning Effort） 控制推理模型内部思考的深度。
低努力模式下，模型思考几步就回答；高努力模式下，模型会反复推敲，考虑更多边界条件。这个参数在 2026 年成为推理模型的重要控制手段：简单任务用低努力，复杂任务用高努力，可以平衡质量和成本。
比如：修复一个简单的语法错误，用低努力就够了；设计一个分布式锁，用高努力更稳妥。
幻觉：模型会自信地编造
幻觉（Hallucination） 是模型最被低估的限制。
模型不是在“撒谎”，而是在“补全”。它的训练目标是预测下一个词，当它不知道答案时，会生成一个看起来合理的答案。
对于代码，幻觉表现为：
todo-cli 这个包”，它可能告诉你“已安装”，但实际上这个包根本不存在。fs.readFileSync 的第三个参数，但实际上这个参数不存在。tsconfig.json 里加 strictNullChecks: true”，但实际上这个选项已经废弃了。为什么幻觉无法完全消除？ 因为模型的训练目标不是“说真话”，而是“预测下一个词”。当它不知道答案时，“编一个合理的”和“承认不知道”都是可能的输出。后训练会鼓励它说“我不知道”，但不能保证在所有情况下都这样。
实用建议：模型说的任何事实性内容都需要验证，尤其是库名、API、配置项。用 AI 写代码时，它生成的每一行涉及外部依赖的代码，都应该查一下文档。
知识截止：模型不知道训练之后的事
每个模型都有训练数据的截止日期。截止日期之后发布的库、框架、API 变更，模型都不知道。它可能给你一个 2024 年有效的方案，但 2026 年已经废弃了。这不是模型的错，是它的知识边界。
怎么应对？
非确定性：同样的输入可能不同输出
即使温度设为 0，模型输出也可能不同。
这是因为底层计算的并行性和浮点数精度问题。GPU 并行计算时，不同批次的浮点运算顺序可能不同，导致结果有微小差异。这些差异在采样时被放大，最终输出可能不同。
这意味着什么？ “同样的提示词，两次运行结果不一样”是正常的，不是 bug。接受这一点，你才不会在调试提示词时陷入“为什么上次可以这次不行”的困惑。
实用建议：不要依赖“精确复现”。如果你需要一个确定的输出，把温度设为 0，并且固定其他采样参数。但即使这样，也不能保证 100% 一致。
本地 vs 云端
本地部署：模型跑在你自己的机器上。
云端部署：模型跑在厂商服务器上。
选哪个取决于你的需求。如果处理的是敏感代码，本地模型更安全。如果追求最强能力，云端模型更好。
量化：把模型压小
量化（Quantization） 把模型参数从高精度压缩到低精度，减小体积、加快推理，但会损失一些质量。常见的有 4-bit、8-bit 量化。4-bit 量化能把模型体积压到原来的 1/4，但质量损失也更大。
微调：让模型适配你的任务
微调（Fine-tuning） 用你自己的数据继续训练模型，让它适配特定任务。
微调成本高、周期长，适合有大量标注数据的场景。对于大多数 AI 编程场景，微调不是必需的——上下文工程和 RAG 通常够用。
低秩适配（LoRA） ：一种轻量级微调方法，只训练一小部分参数，成本低、速度快。
任务-模型匹配框架
模型选型不只是“选最强的”，而是“选最合适的”。按四个维度判断：
| 维度 | 问题 | 影响 |
|---|---|---|
| 任务复杂度 | 需要多步推理吗？ | 复杂任务用推理模型，简单任务用标准模型 |
| 延迟要求 | 能等几秒还是几毫秒？ | 补全要毫秒级用本地小模型，重构可等秒级用云端大模型 |
| 隐私要求 | 代码能上传云端吗？ | 敏感代码用本地模型或零保留云端 |
| 成本预算 | 每天能花多少钱？ | 高频简单任务用小模型，低频复杂任务用大模型 |
具体建议：
| 场景 | 推荐 |
|---|---|
| 简单补全 | 小模型、本地、低延迟 |
| 复杂重构 | 推理模型、云端、接受高延迟 |
| 隐私敏感 | 本地模型或零保留云端 |
| 成本敏感 | 小模型 + 缓存 + 批处理 |
注意：推理模型与普通模型的成本结构不同，详见 §6.3.4。
把上下文窗口当记忆。 上下文窗口是单次调用能看到的，不是模型记住的。下一轮调用，模型看不到上一轮的内容，除非你重新注入。很多人以为“我跟它聊过了，它应该记得”，其实它不记得，是 Harness 在帮你重新注入历史。
把温度当创造力开关。 温度高不会让模型更聪明，只会让它更多样。代码生成应该用低温度。
把幻觉当事实。 模型说的任何事实性内容都需要验证，尤其是库名、API、配置项。
本层小结：模型只负责生成，不负责正确。
本章回答：怎么让模型稳定、可控、可验证地干活？
本章以 CLI 待办工具为例，演示从加规则到加记忆到形成 Agent 的过程。
什么是 Harness
Harness 是围绕 LLM 建立的运行时工程系统。
它不是模型的一部分，而是模型之外的一切。它负责准备工作材料（上下文）、提供行动能力（工具）、维持任务状态（记忆）、限制执行边界（权限）、反馈环境结果（验证），并检查这项工作能不能继续、能不能交付。
一个类比：模型是 CPU，Harness 是操作系统。CPU 负责计算，但光有 CPU 什么都干不了：你需要操作系统来管理内存、调度进程、提供文件系统、处理输入输出。Harness 就是 Agent 的操作系统。
为什么需要 Harness
因为模型有三个天生缺陷：
第一，模型没手。 它只能生成文本，不能读文件、不能执行命令、不能访问网络。你让它“修复这个 bug”，它只能告诉你“应该怎么改”，但不能真的去改。
第二，模型没记忆。 每次调用都是独立的，它不记得上一轮发生了什么。你上一轮告诉它“用 TypeScript”，下一轮它就忘了。
第三，模型没约束。 它会生成任何东西，不管是否安全、是否合规、是否符合项目规范。你让它写一个删除文件的命令，它可能真的写 rm -rf /。
Harness 就是来补这三个缺陷的。工具补“没手”，记忆补“没记忆”，护栏和钩子补“没约束”。
Harness 六层运行闭环
信息边界 → 工具系统 → 记忆状态 → 执行编排 → 评估观测 → 约束恢复。
这个顺序不是随意的，它是一条从输入到输出再到兜底的运行生命周期：先定信息边界，再给工具；有了工具，才需要记住状态；状态明确后，才谈得上编排；编排执行后，才需要评估；评估发现问题，才需要恢复。
每层一句话定义：
可归为一类的概念
有些概念本质上是同一类问题，只是侧重点不同。把它们放在一起看，更容易理解：
四大工程工件
Rules（规则）、Spec（规格）、Skills（技能）、Memory（记忆）。
这四个工件是 Harness 的核心配置。Rules 管永久约束，Spec 管单次需求，Skills 管流程步骤，Memory 管经验积累。它们互不重叠，各有各的位置。
搞混了，就会出现“规则里写了单次需求”或者“规格里写了永久约束”这种问题。比如把“这次提交要修复登录 bug”写进 .cursorrules，下次做别的任务时这条规则还在，就会干扰模型。
Harness 的五个核心职责
把六层闭环抽象一下，Harness 其实就干五件事：
这五个职责覆盖了六层闭环的全部内容。记住这五个，比记住六层更容易。
信息边界层回答的是：模型看到的信息边界在哪？
这一层决定了模型“知道什么”。知道得太多，Token 浪费、注意力分散；知道得太少，回答不准、幻觉增加。
上下文工程是设计和构建一整套动态系统，让模型在正确的时间看到正确的信息。
核心思想：不是一句话，而是一个系统。上下文不是静态模板，而是模型调用前动态生成的整套输入。同一个任务，在不同的代码状态下，需要注入的上下文完全不同。
你改一个函数，模型需要看到这个函数、它的调用方、它的测试、相关的类型定义。你加一个新功能，模型需要看到项目的目录结构、已有的类似实现、项目的依赖。上下文工程要设计的，是这套动态系统。
上下文来源
模型能看到的信息，来自这些地方：
获取机制
怎么把这些信息找出来、注入进去：
@src/utils.ts 或 @getUserById。login、auth、signin 相关的代码。db.query 的函数”。UserService 的模块”。上下文窗口管理
上下文窗口有限，不可能把所有信息都塞进去。需要管理：
上下文质量标准
怎么判断注入的上下文好不好？六个标准：
规则是始终生效的项目级约束，放在 .cursorrules、AGENTS.md、CLAUDE.md 等文件中。
规则的内容包括：项目编码红线、规范、架构约束、常见踩坑记录。
举个例子，你的 CLI 待办工具项目可能有这样的规则：text
|
1 2 3 4 |
- 使用 TypeScript strict 模式 - 所有命令必须支持 --help - 数据持久化使用 JSON 文件，不用数据库 - 错误信息必须包含解决建议 |
规则的写法：什么该写、什么不该写。好的规则是具体的、可执行的、不冲突的；坏的规则是笼统的、模糊的、互相矛盾的。
var，统一用 const 或 let”是好规则——明确、无歧义。规则文件放在上下文开头更好——它每次都一样，可以命中提示缓存（缓存机制见 §3.3.3），降低成本。
系统提示词
系统提示词是 Rules 的传递通道之一。产品身份、工具说明、安全约束也通过它传递。
换句话说，System Prompt 是通道，Rules 是载荷之一。不要把 System Prompt 和 Rules 混为一谈：System Prompt 是 API 层面的概念（system role），Rules 是内容层面的概念（项目约束）。Rules 可以通过 System Prompt 传递，也可以通过 .cursorrules 文件传递。
规格是单次需求的结果与标准。它管结果和标准，不管实现和过程。
比如你要做一个 CLI 待办工具，Spec 会写：
todo add "买牛奶"。Spec 不写：用什么语言、用什么库、怎么组织代码。那是实现，不是规格。
规格与规则的区别：规则是永久约束（“所有命令必须支持 --help”），规格是单次需求（“这次要做 add 命令”）。
意图工程是编码组织目标与价值观，确保上下文充分的 Agent 追求正确结果。
它回答的是“为什么做”。比如：
规范工程是机器可读的企业政策语料库，支撑多 Agent 系统大规模自主运行。
它比意图工程更正式、更结构化。比如：
RAG 是检索后注入上下文。
流程：用户提问 → 检索相关文档 → 注入上下文 → 模型生成。
涉及的技术：
RAG 不等于微调。 RAG 是运行时检索，微调是训练时调整。RAG 适合知识更新，微调适合行为调整；微调也不能解决知识更新：微调后的模型仍然可能不知道最新信息。
很多人问“为什么不用微调让模型知道我们公司的代码规范”。答案是：代码规范会变，微调跟不上变化，RAG 可以。
上下文污染：注入的信息包含错误或过时内容。比如索引了一个废弃的分支。
过时上下文：注入的是旧版本代码。比如缓存没更新。
上下文腐烂：对话轮次增加后，模型对早期上下文的注意力衰减。它忘了你一开始说的约束，忘了最初的目标，忘了之前确定的技术方案。表现：Agent 在第 20 轮时突然用了你第 2 轮明确禁止的库；它重新问了你在第 5 轮已经回答过的问题。应对：定期对对话历史生成摘要，用摘要替换原始历史；把关键约束写入规则文件，而不是只放在对话里；在关键节点重置上下文，重新注入必要信息。
冲突指令：不同来源的指令互相矛盾。比如 .cursorrules 说“用 tabs”，但代码库里全是空格。
工具系统层回答的是：模型能用什么工具、怎么调用？
这一层决定了模型“能做什么”。没有工具，模型只能生成文本；有了工具，模型能读文件、跑命令、搜代码。
工具是模型的手。文件读写、命令执行、代码搜索，这些都是工具。
一个工具通常包含三部分：
工具描述写得清不清楚，直接决定模型会不会用错。比如 readFile 的描述是“读取文件内容”，模型可能用它来读目录。如果描述是“读取指定路径的文件内容，参数是文件路径，不要用于目录”，模型就不容易用错。
模型输出调用意图，Harness 负责执行。
流程：
注意：模型只输出调用意图，不执行。执行是 Harness 的事。
这个区分很重要，因为它意味着：模型不能绕过 Harness 直接操作系统。Harness 可以在执行前检查、在执行后验证。
结构化输出
结构化输出通过 JSON Schema 约束调用意图的格式。模型必须按 schema 输出，否则 Harness 无法解析。
比如你要调用 readFile 工具，schema 规定参数必须是 { path: string }，模型就不能输出 { file: "xxx" }。
结构化输出是工具调用的前置依赖。没有它，Harness 无法可靠地解析模型的意图。
技能是按需加载的操作手册，回答“这类任务按什么步骤做”。
比如：
/commit 技能：检查变更 → 生成提交信息 → 执行提交。/review 技能：读取 diff → 分析问题 → 生成审查意见。/test 技能：找到相关测试 → 运行测试 → 报告结果。技能与规则、规格的区别：
MCP 是统一连接 LLM 与外部工具和数据源的标准。
MCP Server 暴露工具和数据源，MCP Client（通常是 Harness）连接 Server 并调用工具。
2026 年 MCP 完成无状态化重构，支持水平扩容。MCP 生态也爆发了 30 个 CVE，安全成为关注焦点。主要攻击面包括：
A2A 是跨 Agent 通信标准，已发布稳定版。
Agent 卡定义 Agent 的身份和能力。发现机制实现加密签名发现，让 Agent 能找到彼此。
A2A 与 MCP 的区别：MCP 是纵向连接（Agent 连接工具），A2A 是横向通信（Agent 连接 Agent）。
工具描述不清：模型用错工具，往往是描述写得含糊。
参数错误：模型传了错误的参数，比如路径不存在、格式不对。
MCP Server 质量参差：生态里 Server 质量不一，需要甄别。
权限过大：工具能访问的范围超出任务需要。
工具调用失败后的错误分类与处理策略，见 §3.6.4。
记忆与状态层回答的是：跨轮次什么持久、怎么持久？
这一层决定了模型“记得什么”。没有记忆，每次对话都从零开始；有了记忆，Agent 能积累经验、保持状态。
短期记忆是当前会话上下文。长期记忆是跨会话持久化。
持久记忆可靠性是 2026 年的新课题——部署的 Agent 记忆会退化，需要生命周期工程。记忆会过时、会冲突、会积累噪音，需要定期清理和更新。
一个 Agent 如果记住了“项目用 Jest 测试”，但项目已经迁移到 Vitest，它的记忆就是过时的。如果它记住了“用户喜欢简洁的代码”，但用户后来换了风格，它的记忆就是冲突的。
状态管理是长任务的持续、交接与恢复。
持久状态文件是循环工程的核心概念（见 §3.4.6）。Agent 运行到一半，把状态写入文件；下一次运行，从文件恢复状态。这样即使进程重启，任务也能继续。
比如一个 Agent 正在重构模块，它把“已完成 A 文件、正在改 B 文件、待改 C 文件”写入 state.json。进程重启后，它从 state.json 恢复，继续改 B 文件。
提示缓存是成本优化的核心机制。
原理：如果两次调用的前缀相同，第二次调用可以复用第一次的缓存，不需要重新计算。缓存命中价通常仅为未命中价的 1/10。
对于编码 Agent，缓存读取占工作负载成本的大部分，用好缓存可以大幅降低成本。（经济学的完整讨论见 §6.3.2。）
记忆退化：部署久了，记忆过时、冲突、积累噪音。
状态丢失：进程重启后没有恢复，任务从头再来。
缓存失效：上下文前缀变了，缓存命中率骤降，成本飙升。
执行编排层回答的是：多个 Agent 或多次调用之间怎么组织？
这一层决定了“怎么协调”。单个 Agent 能干活，但复杂任务需要多个 Agent 或多次调用配合。
确定性编排：顺序、条件、并行。这些是代码决定的，模型不参与决策。
半自主编排：子代理、代理团队。这些是模型参与决策，但编排逻辑由人/代码设定。
自主性分级整体归 §4.4。
主 Agent 派生子 Agent，子 Agent 独立完成子任务后汇报。
主 Agent 逐轮决策，结果汇总回主上下文。最朴素的落地形态：单 Agent 生成 + 独立 Subagent 验证。
子代理的好处是：子任务可以用独立的上下文，不会污染主上下文。坏处是：子代理之间无法直接通信，需要主 Agent 协调；主 Agent 必须为每个子任务写清楚“要什么、做到什么标准”，否则子 Agent 会按自己的理解自由发挥。这个协调成本经常被低估。
多个 Agent 组成团队，成员之间可以互相通信。领导协调，成员自行协商，共享任务列表。适用场景：多域可独立并行。
代理团队的好处是：成员之间可以互相通信，协作更灵活。坏处是：通信成本高，容易出现文件所有权冲突。
文件所有权冲突：多 Agent 协作最常见的坑
当多个 Agent 同时修改同一个文件时，会出现冲突。Agent A 改了第 10 行，Agent B 也改了第 10 行，合并时冲突。
解决方案：文件锁（同一时间只有一个 Agent 能改）；文件分片（每个 Agent 负责不同的文件）；串行化（把并行改成串行）。实践中，最简单的方案是：让每个 Agent 只负责自己的文件，不交叉。
脚本持有编排逻辑，中间结果不占用主对话上下文。
与子代理的关键区别是“谁持有计划”：子代理由模型逐轮决定，工作流由脚本持有。
动态工作流的好处是：可复现、可调试、不占用主上下文。坏处是：不够灵活，遇到意外情况需要人工干预。
一个 API 层编排多个厂商 Harness。
2026 年 Harness 从工具转向平台：可导入 SDK、市场、切换成本工具、企业治理层。
循环工程是设计“替你提示 Agent”的系统：触发、停止、状态、验证、预算、升级。
（演进背景见 §1.5。）
把几种编排形态放在一起对比：
| 形态 | 谁持有计划 | 适用场景 | 主要代价 |
|---|---|---|---|
| 确定性编排 | 人/代码 | 流程固定 | 不灵活 |
| 子代理 | 主 Agent 持有任务分配计划，子 Agent 持有子任务执行计划 | 子任务可独立 | 通信需主代理协调 |
| 代理团队 | 成员协商 | 多域并行 | 通信成本、文件冲突 |
| 动态工作流 | 脚本 | 流程可复现 | 意外需人工干预 |
常见坑：
评估与观测层回答的是：怎么知道它做对了、做到什么程度？
这一层决定了“怎么判断”。没有评估，Agent 不知道自己做得对不对；没有观测，人不知道 Agent 在干什么。
测试执行、静态检查、错误分类与重试。
Agent 做完一步，运行测试，根据结果决定下一步。这是最基本的反馈闭环。没有反馈闭环，Agent 就是盲人摸象。
生成者与验证者必须独立。上下文共享是自查失效的核心根源。
如果生成者和验证者共享上下文，验证者会继承生成者的偏差，无法发现生成者的问题。所以验证者必须用独立的上下文、独立的模型、独立的提示。
对抗验证是对抗式独立验证在编排层的一种实现：让两个 Agent 互相审查对方的发现，再汇总报告，用独立的视角挑战生成结果。
在 Harness 运行时判断输出是否合格。
比如：生成的代码能不能编译？测试能不能通过？格式是否符合规范？
智能体可观测性捕获推理链、所选动作和决策历史的不可变记录，是运行期观测视角。
传统监控工具无法解释自主系统为何做出某个决策。可观测性要回答的是：Agent 为什么选了这个工具？为什么走了这条路？为什么放弃了那个方案？
运行期观测服务于调试，消费者是开发者；企业级观测服务于审计，消费者是合规官（见 §6.7.4）。
验证者继承生成者偏差：生成者和验证者共享上下文，验证形同虚设。
观测缺失：没有记录决策历史，出问题后无法回溯。
与 3.6 的关系：评估观测和约束恢复是一体两面：验证发现错误，恢复处理错误。3.5 负责“判断”，3.6 负责“处置”。
约束校验与恢复层回答的是：出错了怎么救、怎么防止出错？
这一层决定了“怎么兜底”。没有约束，Agent 可能闯祸；没有恢复，Agent 出错后无法补救。
护栏是输入输出与工具调用的安全约束。
钩子是绑定生命周期事件的强制执行。
钩子类型：调用前、调用后、工具调用前、工具调用后、文件保存、提交前。
钩子能做什么：注入上下文、校验输出、格式化代码、触发测试、记录日志、阻止危险操作。
Rule 是建议，Hook 是强制。Hook 可以直接阻断工具调用。比如你可以设置一个 Hook：任何 rm -rf 命令在执行前必须人工确认。
工具调用和任务执行不会总是成功。先把错误分类：
处理策略：区分可重试和不可重试错误；参数错误让模型修正后重试；权限不足停下来问人；超时用指数退避重试（重试间隔逐渐增加）；工具本身出错记录日志并降级。重试失败后，可以降级模型：换一个更简单的模型或方案。
无限重试：同一个错误反复重试，消耗预算。
重试放大错误：重试本身加剧了问题（比如重复提交）。
钩子过多导致不可预测：钩子逻辑互相干扰，行为难以推断。
本层小结：Harness 的质量，决定模型能力的兑现率。
拆解公式第三项：自主循环。前两项（模型、Harness）已在第 2、3 章讲完，本章讲第三项。
Harness 的编排是“人/代码决定怎么编排”，Agent 的自主循环是“模型自己决定下一步”。前者是编排机制，后者是自主决策。本章讲的是后者。
Harness 让模型能干活，但每一步干什么，还是人/代码决定的。Agent 层要解决的，是让模型自己决定下一步。
这就是“自主循环”的含义：不是更聪明的模型，而是把模型放进一个循环里，让它自己观察、思考、行动、反思。
Agent 循环是：观察 → 思考 → 行动 → 反思。
观察：Agent 先看当前状态。读文件、看错误、检查测试结果、查看 git 状态。它需要知道“现在是什么情况”。
思考：根据观察到的状态，决定下一步做什么。是继续写代码？还是先跑测试？还是问用户一个问题？
行动：执行决定。写代码、运行命令、调用工具、修改文件。
反思：检查行动的结果。测试通过了吗？目标达成了吗？有没有引入新问题？
然后回到观察，开始下一轮循环。
用 CLI 待办工具演示：你告诉 Agent“给待办工具加一个优先级功能”。
todo.ts、storage.ts、cli.ts，查看现有代码结构。它看到 Todo 接口目前只有 id 和 text。Todo 加 priority 字段，需要修改存储逻辑，需要加 CLI 参数。Todo 接口，加 priority: 'low' | 'medium' | 'high'。修改 storage.ts，序列化和反序列化时处理 priority。修改 cli.ts，加 --priority 参数。这个循环看起来简单，但它是 Agent 区别于普通工作流的关键。普通工作流是“步骤 1 → 步骤 2 → 步骤 3”，Agent 循环是“做一步，看结果，再决定下一步”。前者是人/代码决定下一步，后者是模型自己决定下一步。
循环的终止条件
Agent 不能永远循环下去。它需要在某些条件下停下来：
没有终止条件的 Agent 会陷入无限循环，反复执行同一步骤，消耗大量 Token 却毫无进展。
Agent 循环有三种常见实现模式：
ReAct：推理 + 行动交替进行
ReAct 是最基础的 Agent 模式。它的流程是：想一步，做一步，再看结果。
比如修一个 bug：
src/auth.ts 第 42 行。ReAct 适合大多数任务。它的优点是灵活，能根据实际情况调整。缺点是每一步都要调用模型，成本高、速度慢。
Plan-and-Execute：先规划再执行
Plan-and-Execute 的流程是：一次性想清楚所有步骤，然后逐步执行。
比如重构一个模块：
Plan-and-Execute 适合步骤明确、依赖清晰的任务。优点是效率高，不需要每步都调用模型。缺点是如果规划错了，后面全错。
Reflection：执行后反思
Reflection 的流程是：做完一步，回头看有没有问题，再决定下一步。
比如写一个函数：
Reflection 适合需要迭代优化的任务。缺点是每步都反思，成本高、速度慢。
什么时候用哪种？
实际产品往往混合使用。比如先用 Plan-and-Execute 规划，再用 ReAct 执行每一步，最后用 Reflection 检查结果。
Agent 面对复杂任务时，需要先拆解。怎么把“做个登录页”拆成可执行步骤？
未知项管理
任务拆解的核心是识别未知项。有四类未知：
好的 Agent 会先处理已知和可知，再通过探索发现隐性，最后在遇到未知时停下来问人。
规划失败后的重规划
规划不可能一次就对。执行过程中发现原计划行不通，需要重规划。
重规划的关键是：保留已完成的部分，只调整未完成的部分。不要从头再来，那样浪费太多。
Level 0 补全 → Level 1 聊天 → Level 2 生成 → Level 3 重构 → Level 4 自主智能体。
这是类比分级，便于理解自主性光谱，不是行业标准。实际产品往往跨越多个级别。
比如 Cursor 的 Tab 补全是 Level 0，Chat 是 Level 1，Composer 是 Level 2 到 3，Agent 模式是 Level 4。Claude Code 的交互模式是 Level 1 到 2，自主模式是 Level 4。
每个级别的能力边界和人类介入程度：
级别越高，人类介入越少，但风险也越大。所以需要根据任务的风险选择合适的级别。
不同形态适合不同场景。IDE Agent 适合日常编码，CLI Agent 适合自动化，PR Agent 适合独立任务，云端 Agent 适合长时任务。
多 Agent 的编排机制（子代理、代理团队、动态工作流）已在 §3.4 展开。本节从 Agent 自主决策的视角看协作：什么时候让模型自己决定“派子代理、组团队、接力”，什么时候用固定编排？
判断标准仍然是“谁决定下一步”：
自主协作的判断框架
自主协作的三个代价
一个务实的建议：从最小协作开始。能用一个 Agent 完成的任务，不要拆成多个；确定需要协作时，优先用主从模式（主 Agent 协调、子 Agent 执行），因为它最容易审查和回滚。
Agent 自己的记忆，和 Harness 的记忆（§3.3）不同。
Harness 的记忆是“这次任务中，上一轮发生了什么”——任务级的状态持久化。Agent 的记忆是“跨任务，我学到了什么”——经验的沉淀。
比如：Agent 在多次任务中发现，这个项目总是用 vitest 而不是 jest。它把这个记下来，下次直接假设用 vitest。
Agent 记忆的挑战和 §3.3.1 一样：记忆会过时（项目迁移了测试框架）；记忆会冲突（不同项目用不同框架）；记忆会积累噪音（记了太多不重要的细节）。需要定期清理和更新。
Agent 越自主，风险越大。它能读文件、执行命令、访问网络，这些能力用错了就是灾难。所以需要：
src/ 目录，不能写 .env。git revert、数据库事务。分工说明：本节讲开发过程中 Agent 需要什么权限和沙箱；运行时兜底机制（护栏、钩子、断路器）见 §3.6；企业治理框架见 §6.7。
rm 删除了不该删的文件。本层小结：Agent 不是更聪明的模型，是更完整的系统。
产品层回答的是：人怎么用、团队怎么协作？
前三层讲的是技术，产品层讲的是人。技术再好，如果工作流不对、协作方式不对，AI 也发挥不出价值。
不同形态适合不同场景。选错了形态，效率反而降低。比如代码补全适合 IDE 插件，因为你不想离开编辑器；自动化测试适合 CI 集成，因为你需要每次提交都跑；代码审查适合 PR 机器人，因为你需要它自动分析 diff。
补全 → 聊天 → 生成 → 重构 → 自主智能体。
从补全到自主智能体，人的介入程度逐渐降低：
注意：自主性光谱（§4.4）讲的是 Agent 的能力级别，工作流光谱讲的是人的使用方式。前者是技术维度，后者是人的参与维度。两者有关联，但角度不同。
人在回路光谱：人在环中（每一步都审批）、人在环上（关键节点审批）、人在环外（完全自主）。
选哪个级别，取决于任务的风险和你的信任程度。高风险任务用人在环中，低风险任务用人在环外。比如修复生产环境的 bug，用人在环中；生成单元测试，用人在环外。
规格作为“可执行真相来源”，不是一次性规划文档。
工作流：提案 → 规格 → 设计 → 任务。
用 CLI 待办工具演示：你要加一个“标签”功能。
todo add "买牛奶" --tags 购物,生活 能正常添加。Todo 接口加 tags: string[]，修改存储逻辑，修改 CLI 解析。先写清楚要做什么、做到什么标准，再让 AI 实现。规格需要和代码一样有版本控制、审查、测试。
为什么规格要“可执行”？ 因为如果规格只是文档，它很快就会过时。如果规格是可执行的（比如测试用例、验收标准），它就能持续验证代码是否符合要求。比如你把“登录功能必须支持邮箱和手机号”写成测试用例，每次提交都跑。这样规格永远不会过时，因为它就是测试。
先写测试，再让 AI 实现。质量门禁。独立验证在工作流中的应用（机制详见 §3.5.2）。
验证优先开发的核心思想是：不要等 AI 写完再检查，而是先定义“什么叫对”，再让 AI 去实现。
这样 AI 有一个明确的目标，你有一个明确的验收标准。而且测试是独立的：它不依赖 AI 的实现，只依赖规格。
复现问题、日志分析、二分定位、最小补丁。
调试是 AI 编程中最容易被低估的环节。AI 能生成代码，但不一定能修 bug。
修 bug 需要：
AI 可以加速每一步，但不能替代每一步。
AI 生成，人负责。
多智能体代码审查：多个 AI 审查器协同分析 PR，验证发现以降低误报。
智能体变更管理：按业务价值/风险/紧迫性排序 PR。
AI 能加速审查，但不能替代审查。最终责任在人。
从“随性对话”到“系统化指挥 Agent”。Karpathy 提出的 Agentic Engineering 是 Vibe Coding 的进化版。
Vibe Coding 是“感觉对了就行”，Agentic Engineering 是“在保持质量标准的前提下快速前进”。后者才是可持续的。
截图生成代码、设计稿转代码、多模态验证（生成的 UI 与设计稿对比）。模型能力见 §2.2、§2.3。
多模态编程让“照着设计稿写页面”从手工翻译变成自动生成。但它也有局限：生成的代码可能不符合项目规范，需要人工调整。
提示模板、规则文件、审查清单、禁入区。
团队规范的核心是：把个人的最佳实践变成团队的默认行为。
本层小结：Product 决定工作流，工作流决定 AI 的实际价值。
本章不是第五个平行层，而是跨层主题索引。每个主题的主位在各自章节，本章做跨层扩展联系和深化。
机制主位：§3.6.1 护栏。形态主位：本章。
威胁形态
rm -rf 删除了整个项目。攻击向量
AGENTS.md 或 .cursorrules。下次 Agent 运行时，自动读取这个文件，恶意指令自动生效。架构隔离：唯一可靠的防御
没有单一检测或过滤技术能可靠阻止提示注入。自适应攻击下，绕过率超过 90%。唯一可靠的方案是架构隔离：确保 Agent 不会同时处理不可信输入和可信指令。
具体做法：把处理不可信输入（读文件、读网页）的 Agent 和处理可信指令（执行操作）的 Agent 分开。前者只负责读取和总结，后者只负责执行，两者不共享上下文。
各层的安全责任
生成代码能不能商用？这取决于模型厂商的服务条款和生成代码与训练数据的相似度。
如果生成的代码与某个开源项目高度相似，可能涉及许可证问题。实践中，大多数厂商承诺“不主张生成代码的版权”，但这不意味着你可以无视开源许可证。
实用检查清单
本章不展开训练数据版权与企业合规审查。这些是法律问题，不是工程问题。
机制主位：§3.3.3 提示缓存。形态主位：本章。
Token 计费
按 Token 数量收费，包括输入和输出。不同模型价格差异巨大：小模型可能 $0.10/百万 Token，大推理模型可能 $15/百万 Token。一个编码 Agent 的任务可能消耗几十万 Token，成本从几分钱到几块钱不等。
缓存经济学
提示缓存是成本优化的核心（机制见 §3.3.3）。如果两次调用的前缀相同，第二次可以复用缓存，成本降到 1/10。
对于编码 Agent，缓存读取占工作负载成本的大部分。用好缓存可以大幅降低成本。这就是为什么规则文件放在上下文开头更好：它每次都一样，可以命中缓存。
模型路由
根据任务复杂度选择不同模型：简单补全用小模型，复杂重构用推理模型。这叫模型路由。好的路由策略可以在保证质量的前提下降低成本 50% 以上。
模型成本分化
推理模型的成本结构和普通模型不同。一个具体对比：同一个编码任务，标准模型可能消耗 1500 Token（1000 输入 + 500 输出），成本约 $0.003；推理模型可能消耗 4500 Token（1000 输入 + 3000 内部思考 + 500 输出），成本约 $0.015，是标准模型的 5 倍。选型时要把这部分算进去。
机制主位：§3.5 评估与观测层。形态主位：本章。
基准测试
按评估层级从低到高：
指标
评估集 / 黄金样例 / 自动评分器
Evals 是结构化的测试集。Goldens 是理想输出的参考标准。Autoraters 是用 LLM 自动评分。
爬山法迭代
基线评估 → 分析失败 → 针对性改进 → 重新评估 → 循环迭代。这是提升 AI 编程质量的标准方法。
本地与实时差距
SWE-Serve 显示，约三分之一通过本地测试的补丁在实时服务环节失败。本地测试通过不等于生产环境可靠。
上下文债务 / 意图债务
每个没有设计好上下文、意图和规范的 Agent 都会积累工程债务。上下文债务是“上下文没管好”，意图债务是“意图没编码清楚”。它们不会立刻出问题，但会在某个时刻集中爆发。
验证、审查、责任归属。
信任校准：何时该信 AI、何时必须验证。
任务、隐私、预算、团队、生态。
任务决定能力需求，隐私决定部署方式，预算决定模型档次，团队决定协作方式，生态决定工具链。
机制主位：§3.6.3 运行时治理。形态主位：本章。
企业治理框架
Agent 身份
每个 Agent 应被视为独立身份，明确所有权和访问权。维护 Agent 集中注册表，应用动态最小权限访问控制。
策略即代码
将业务和监管要求直接编码到 Agent 操作中。治理从书面策略转向运行时强制执行。
审计追踪
记录每个决策的依据。高影响操作需要人工审批。根据风险定义自主层级和升级规则。
非人类身份框架
Gartner 建议：每个内部和第三方 Agent 视为独立身份，Agent 接收临时访问权限，任务完成后撤销。
企业级可观测性
治理视角的可观测性：审计日志与合规证据，用于回答“这个 Agent 做了什么、依据是什么”。运行期观测服务于调试，消费者是开发者；企业级观测服务于审计，消费者是合规官。（运行期观测机制见 §3.5.4。）
AI 编程领域概念迭代速度快，目录无法一次穷尽。本章只收“可能改变骨架”的概念，不收产品名、单次热点、基准名、攻击技术名。
触发条件：
三个条件都满足时，从 7.2 移入正文对应章节，7.2 只保留一行索引。
复用“谁决定下一步”判据，按“最先发生变化的地方”定主位。
来源：arXiv、InfoQ/QCon、Anthropic/OpenAI 工程博客、热门 Agent 框架 changelog。频率：每季度复查一次。原则：宁可漏收，不要错收。
模型相关
Harness 相关
.cursorrules 等文件中。Agent 相关
上下文相关
评估相关
开发方法
安全相关
新概念
术语关系图text
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
Agent ├── Agent Loop（观察→思考→行动→反思） │ ├── ReAct（推理+行动交替） │ ├── Plan-and-Execute（先规划再执行） │ └── Reflection（执行后反思） ├── Agent Forms（形态） │ ├── IDE Agent │ ├── CLI Agent │ ├── PR Agent │ ├── 测试 Agent │ ├── 循环 Agent │ ├── GUI Agent │ └── 云端 Agent └── Multi-Agent（多 Agent） ├── Subagents（子代理） └── Agent Teams（代理团队） Harness ├── 信息边界层 │ ├── Context Engineering │ ├── Rules / System Prompt │ ├── Spec │ └── RAG ├── 工具系统层 │ ├── Tools │ ├── Tool Calling / Function Calling │ ├── Skills │ ├── MCP │ └── A2A ├── 记忆状态层 │ ├── Memory │ ├── State Management │ └── Prompt Caching ├── 执行编排层 │ ├── 确定性编排 │ ├── Subagents │ ├── Agent Teams │ ├── Dynamic Workflows │ ├── Meta-Harness │ └── Loop Engineering ├── 评估观测层 │ ├── Feedback Loop │ ├── Independent Verification │ └── Agentic Observability └── 约束恢复层 ├── Guardrails ├── Hooks ├── Agent Runtime Governance └── Error Classification & Retry |
把 AI 当放大器，不是替代品。
模型负责生成，Harness 负责稳定，Agent 负责自主，产品负责协作。四层各司其职，缺一不可。
理解这套结构，你就知道每个新概念该放在哪一层、解决什么问题。下次看到一个新词，问自己“谁决定下一步”，答案自然就出来了。
AI 编程的工程重心还在演进。从提示到上下文，从上下文到 Harness，从 Harness 到循环——每一次叠加，都是因为前一层解决不了新问题。理解这条演进线，你就不会在新概念出现时感到迷茫，而是能判断它属于哪一层、解决什么问题。