从 Prompt 到 Loop：理清 AI Agent 工程的概念演进

Prompt EngineeringLLM 时代的调参如果说传统机器学习的调参是需要考虑特征权重与统计边界的寻优而深度学习时代的调参是摸索网络架构与梯度下降的动力学那么 LLM 时代的‘调参’就是 Prompt Engineering——通过自然语言的上下文来激活知识与对齐意图。Prompt Engineering 解决的核心问题是面对一个具体任务如何用一段精心设计的自然语言输入包括指令、示例、格式约束、推理引导等让模型在一次调用中就给出准确、符合预期的输出具体包含几个子问题怎么把任务讲清楚指令的措辞、结构、强调方式让模型准确理解你的意图而不是字面解读后跑偏要不要给示例用 few-shot examples 展示期望的输入输出模式借助模型的 in-context learning 能力让它快速习得任务规律要不要引导推理通过 Chain-of-Thought 等技巧让模型显式生成中间推理步骤在数学、常识、符号推理等任务上提升准确率怎么约束输出格式JSON / Markdown / XML、风格、范围限制让结果可解析、可复用、可被下游系统消费这里也包含两部分考虑让结果更准通过措辞、结构、示例、推理引导把模型一次做对的概率拉到最高让结果更稳定通过温度控制、Schema 约束、Self-Consistency 等降低输出的随机性让相同输入产生可复现的结果在模型还比较弱的时代2022-2024prompt 的好坏极大程度地影响了生成质量。当时 agent 的概念还没有兴起人们更多关注的就是这个单次调用如何更好出结果的问题。那个时期积累了大量调参技巧#技巧背后的原理 / 实证1重要信息放开头和结尾Transformer 注意力在长上下文中呈 U 型衰减中间位置容易被忽略Lost in the Middle。2025 年先进模型依然存在GPT-4o 在 32K 上下文时准确率从 99.3% 掉到 69.7%2输出结构化数据时优先用类型/Schema 描述而非自然语言描述模型在预训练中见过大量代码与类型定义语料对 TypeScript interface / JSON Schema / Pydantic 这类结构化描述的识别与遵守度显著优于自然语言描述3关键约束用强调标记并复述 1-2 次重复关键指令能强化注意力权重已被实证列入可测量提升 LLM 准确率的 prompt 原则之一4对推理类任务加上 CoT 引导让模型显式生成中间推理步骤Chain-of-Thought在数学、常识、符号推理任务上大幅提升表现。最简单形式prompt 末尾加 Lets think step by step5对有客观正确解的任务使用 Self-Consistency在较高温度下采样多条推理链、对最终答案做多数投票能显著提升准确率6给 2-5 个高质量示例Few-shot大模型具备 in-context learning 能力无需梯度更新就能从示例中习得任务模式7要稳定/可重复的输出时把温度调到 0低温使 softmax 趋近 argmax输出趋向贪心解码、随机性显著下降。即使温度0 仍存在一定隐藏随机性但已经足够稳定8长上下文末尾完整重复一次核心提示词打破因果语言模型从左到右单向阅读的注意力物理局限使模型处理第二遍时能全局回溯。Google Research 2025 年研究证实这种 prompt 复述 在非 reasoning 模式下普遍提升性能但很多技巧在模型强大并引入推理能力之后变得没那么重要了。现在的 prompt 变得更简单更直观讲清楚你想要做的事情。当然如果想要达到更极致的效果或者使用一些本地模型、小模型这些技巧仍然有价值。但很快大家发现单纯调 prompt 远远不够。即使 prompt 构建得再好如果没有把必要的知识领域知识、上下文信息放进上下文里最终效果还是会很差LLM 的幻觉会很严重。这就引出了 Context Engineering。二、Context Engineering给模型看什么Context Engineering 解决的核心问题是我有一堆信息和上下文应该给模型看什么以及怎么给具体包含两个子问题选什么内容放到 LLM 的上下文中从海量数据中检索相关信息已经选好了上下文后怎么给到模型内容的排序、格式化这里包含了两部分考虑让结果更准放的内容和格式会影响 LLM 的输出质量让成本更低context window 是稀缺资源要高效利用还要从推理效率上考虑成本Context Engineering 不是 Prompt EngineeringContext Engineering 和 Prompt Engineering 的区别在于Prompt 关心怎么说Context 关心给什么信息。你的 prompt 可以写得很完美但如果缺少必要的领域知识、业务上下文、关键信息模型一样会产生幻觉。这个视角的转变在 2025 年中已经成为行业共识的关键节点。Shopify CEOTobi Lütke在 2025 年 6 月公开表态I really like the term context engineering over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.(我更喜欢 context engineering 这个词而不是 prompt engineering。它更准确地描述了这项核心技能为任务提供所有相关上下文让 LLM 有可能解决这个任务的艺术。)紧接着Andrej Karpathy公开背书并给出了更工程化的定义1 for context engineering over prompt engineering. People associate prompts with short task descriptions youd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step.(1赞成用 context engineering 替代 prompt engineering。人们会把 prompt 联想到日常使用 LLM 时给的一小段任务描述。但在每一个工业强度的 LLM 应用里context engineering 是一门精细的艺术与科学为下一步把恰到好处的信息填进 context window。)prompt 这个词容易让人联想到写一句措辞精巧的指令但真正决定模型表现的是把哪些信息、以什么形式、按什么顺序塞进 context window——这是一个系统工程问题而不是文学问题。Karpathy 强调人们把 prompt 联想成短小、措辞巧妙的指令但真正的技能要宽得多——它涵盖信息检索、工具结果、对话历史、示例选择的整套组装工作。Context Engineering 的关键维度Context Engineering 涉及多个维度的优化先把 6 个维度并列出来一览#维度核心关注点1外部知识的检索与组织从外部知识库找内容、决定排序方式2工具定义与 Schema 设计向模型描述有哪些能力可用3对话历史与记忆管理保留什么、丢弃什么、怎么跨 session 检索4格式与结构化用什么格式纯文本 / Markdown / XML / JSON让模型认知负荷最低5Token Budget 管理何时压缩、何时 offload、何时读回6Context Caching把稳定不变的内容标记为缓存前缀命中即 0.1× 价格下面逐项展开。1. 外部知识的检索与组织这是最典型的场景包括RAG检索增强生成从外部知识库检索相关内容语义检索使用向量嵌入进行相似度匹配Reranking对检索结果进行二次排序关键原文顺序 vs 相关度顺序传统 RAG 按相似度降序排列检索结果但这会破坏文本的逻辑流、时序进展、指代关系。保持原文顺序OP-RAG能用更少的 token 实现更好的效果2. 工具定义与 Schema 设计Context Engineering 也包含如何向模型描述可用的工具Tool schema 的结构化JSON Schema、TypeScript interface、Function signatureTool description 的清晰度决定模型能否正确选择和调用工具参数说明的精确性影响工具调用的参数准确率这部分看似是工具定义但本质上是在构建模型的上下文——告诉模型有哪些能力可用。3. 对话历史与记忆管理对话历史的压缩与过滤保留关键信息丢弃冗余内容长期记忆的检索从历史对话中提取相关上下文工作记忆的维护当前任务的临时状态4. 格式与结构化不同的格式对模型的认知负荷差异巨大格式适合场景注意点纯文本向量嵌入构建Token 利用率最高Markdown文档/对话模型原生认知结构预训练语料大量存在理解力可提升XML 标签多文档边界控制严格边界防止多文档语义污染JSON / YAML数据交换高认知负荷容易产生语法正确但内容幻觉的输出5. Token Budget 管理在有限的上下文窗口内什么时候触发 compaction压缩哪些内容 offload 到磁盘如何按需读回之前的内容6. Context Caching上下文缓存在 agent 的实际运行中绝大多数 token 是被反复重发的system prompt、tool schemas、few-shot 示例、规则说明、长文档背景——这些内容每次工具调用都会原封不动地塞回 context window。Context caching 就是针对这一现象的工程优化把稳定不变的内容标记为缓存前缀只为第一次付比较昂贵的cache write的费用之后命中缓存基本只需要1/10的cache read的价格。以 Anthropic prompt caching 为例量级差异是显著的维度数值备注写入cache write1.25× base input price只付一次读取cache hit0.1× base input price比正常 input 便宜 90%首 token 延迟TTFT下降约85%—TTL默认 5 分钟可延长至 1 小时—对一个典型的 coding agent 而言system prompt tool definitions 动辄上万 token每一轮工具调用都重复发一次。如果不做 caching这一块就是持续不断的成本黑洞做了 caching 之后它从每轮都要付的过路费变成了一次性投入 极低的复用成本。要让缓存真正命中工程上有几条原则原则做什么反面教材Stable prefix把不变的内容放在 context 最前面动态内容用户消息、工具结果、时间戳放后面任何前缀位置的字符变动都会让后面的缓存失效避免无谓的破坏检查前缀里不要混入会变的内容日期、随机 ID、自增计数器这类看似无害的字段如果放在前缀里会让整个缓存秒级失效——这种坑在生产中非常常见Context Engineering 的局限Context Engineering 解决的是已经选好内容后怎么组织的问题。它假设你需要的信息是可获取的、有边界的——但真实场景下单靠组织上下文是远远不够的Agent 怎么主动去找信息工具调用、检索流程Agent 如何安全地运行沙箱、权限Agent 如何跨多个 session 持续工作状态持久化、调度什么时候应该把上下文压缩、卸载、读回生命周期管理这些是 Context Engineering 本身回答不了的——它们关心的不是模型这一步看什么而是整套系统怎么运转。要回答这些问题需要把视角从单次调用的上下文抬升到整个 agent 系统的工程框架这就是下一节要展开的主题。三、Harness EngineeringAgent Model Harness到了 Harness Engineering 这一层视角发生了根本性的转变。如果说 Prompt 和 Context Engineering 关注的是怎么跟模型说话和给模型看什么那么 Harness Engineering 关注的是如何把模型变成一个可以信赖的、能自主完成任务的 Agent。Harness的定义简洁却带来了混乱按照 LangChain 的定义Agent Model Harness也就是说模型之外的所有东西都是 Harness。这个定义很简洁但在实践中会导致混乱你说Harness可能指的是 Claude Code 这个产品我说Harness可能指的是 Initializer Coding Agent 这种设计模式他说Harness可能指的是他项目里的 AGENT.md 配置文件三个人用同一个词说的完全不是同一个东西。这就像说软件工程——你可能在说设计模式也可能在说编程语言也可能在说某个具体的代码库。问题的根源在于:Harness 的范围太广了。如果不对 Harness 进行分层我们就无法精确讨论问题。解决手段就是将Harness再拆一拆拆成多个可以用来讨论的概念.Harness 的分层结构为了解决Harness 范围太广的问题我结合了 Anup Jadhav、Anthropic、学术界的研究提出了一个从底层到上层的分层结构:层名称性质回答的问题典型内容第 5 层Design Instance实际场景具体 Policy为了某个目标怎么组合Claude Code、Stripe Minions、CI/CD Auto-Fix第 4 层Pattern可复用模式可复用 Policy一组能力该怎么组合Plan-Act-Verify、Initializer Coding Agent、Loop第 3 层Design ComponentsDesign Axes上层 Mechanism有哪些可选项10 个 Design Axestopology / coordination / memory ...第 2 层Frameworkmechanism / runtime底层 Mechanism能做什么Tool dispatch、Sandbox、MCP、Skill、Trigger ...第 1 层Cross-cutting Concerns横切基础横切所有层贯穿全程的基础能力Prompt Engineering、Context Engineering依赖方向第 5 层实例化自第 4 层第 4 层组合自第 3 层第 3 层实现于第 2 层所有层都依赖第 1 层Cross-cutting Concerns。这个分层可以借经典的软件工程原则Mechanism vs Policy机制与策略分离来理解:层Mechanism / Policy角色Cross-cutting Concerns横切基础贯穿所有层的基础能力Framework底层 Mechanism让能力真实可执行Design Components上层 Mechanism提供可组合的能力组件和设计坐标Pattern可复用 Policy决定一组能力如何组合Design Instance具体 Policy真实跑起来的系统配置与运行方式也就是说下面三层回答的是系统能提供哪些能力、有哪些可选项上面两层回答的是为了某个目标应该怎么组合这些能力。让我们从底层开始逐层展开。第 1 层Cross-cutting Concerns横切基础这一层是所有其他层都依赖的基础。Anup Jadhav 明确指出Harness engineering subsumes both prompt engineering and context engineering.(Harness engineering 同时涵盖 prompt engineering 和 context engineering。)横切能力关注的核心问题典型内容Context Engineering每步给模型什么内容RAG、retrieval、tool schema、compaction 触发时机、offload 策略Prompt Engineering单次输入的措辞CoT、few-shot、强调标记为什么说它们是横切的因为无论你在哪一层Framework、Pattern、还是 Instance都需要考虑在哪一层都要回答FrameworkTool schema 怎么写Prompt EngineeringPatternPlanner 给 Evaluator 什么提示Prompt ContextInstanceAGENT.md 里要包含哪些上下文Context Engineering它们不是独立的层级而是贯穿所有层的基础能力。第 2 层Frameworkmechanism / runtimeFramework 层是 Harness 分层的基础它提供底层的能力。这一层回答的是能做什么而不是怎么做。典型的 Framework 产品Claude CodeCodex SDKOpenAI Agents SDKLangGraphDeep AgentsFramework 提供的核心机制Mechanism核心能力 / 关键说明Tool dispatchTool registry注册可用工具Schema 注入把工具签名注入 contextJSON tool-call 协议标准化的调用格式Sandbox runtime隔离执行环境文件系统沙箱Shell 环境管理MCP client外部 tool/data 的标准接入MCP server lifecycle 管理Tool description 注入⚠️ 信任边界需要审计Skill registrySkill 发现机制Progressive disclosure 触发Skill 文件格式规范Subagent spawnContext isolation每个 subagent 独立的 context windowEvent-driven wait父 agent 不轮询等 subagent 完成后被通知→ 避免父 agent 上下文膨胀Hook lifecycleBefore/after tool call、on session start、on errorDeterministic enforcementsuccess is silent, failures are verbose (成功时保持安静失败时输出详细信息)把我跟 agent 说要做 X变成系统强制 XPermission gateDestructive action 拦截git reset --hard、rm -rfHuman approval 流程细粒度权限配置Trigger 系统Cron / event / webhook → 启动新 session可用于自动化调度场景trigger 系统本身是 framework 能力ObservabilityTrace、logging、event busCost tracking、latency monitoring调试工具inspector、replayMechanism vs Policy 的边界这是最容易混淆的地方。举个例子Mechanism 提供Trigger 系统能够定时启动 session 的能力Policy 决定什么时候触发、触发后执行什么agent。Mechanism 提供Skill registry能够注册和触发 skill 的能力Policy 决定有多少个 skill、每个 skill 的内容是什么、触发条件是什么Mechanism 提供Subagent spawn能够启动子 agent 的能力Policy 决定拆分成几个 subagent、职责是什么、用什么模型这就是 Mechanism vs Policy 的分离Framework 和 Design Components 暴露能力Pattern 和 Design Instance 决定如何组合、何时使用、做到什么程度。第 3 层Design ComponentsDesign Axes这一层我称之为Design Components。它由一组Design Axes构成——这些 axes 描述了设计 Harness 时的选择空间。它们仍然偏Mechanism因为只告诉你有哪些选项并不直接替你决定该怎么用。这一层回答一个问题设计 Harness 时有哪些维度需要决策