2026-07-23 Agent 架构演进：从 Prompt 到 Graph 的工程化路径#

📅 学习日期：2026-07-23 | 📚 来源：AI Agent 知识库 | 📝 综合文章数：5 篇

为什么选这个主题#

这是学习笔记的第一篇，选 Agent 架构演进作为起点，因为它提供了整个知识库的核心概念坐标系——Prompt、Context、Harness、Loop、Graph 这些概念贯穿后续几乎所有文章。理解了这条演进主线，再学任何具体技术（Memory、Skill、Tool）都能找到它的位置。另外，你昨天刚读完一篇 LangGraph 的文章，今天这个主题正好从更高维度回答了”为什么要有 Graph”这个问题。

核心要点#

要点 1：模型是引擎，但引擎不是汽车——分层递进是不可回避的工程事实#

所有 5 篇文章都认同同一个起点：大模型是”裸 CPU”，它有语言理解和推理能力，但先天缺四大件——上下文窗口瓶颈（128K 物理上限）、注意力稀释（有效容量 ≠ 物理容量）、数据搬运谬误（搬数据易丢字段）、无状态（每次对话如新生）。

正因为这些先天约束，你不可能靠一层优化就把 Agent 做稳。5 篇文章描绘的演进路径是层叠递进的：

层级	核心问题	解决了什么	留下了什么瓶颈
Prompt Engineering	我该对模型说什么？	单次交互质量提升，活动效率+50%	指令遵从率随步骤骤降（10步<70%），无容错，上下文气球膨胀
Context Engineering	我该让模型看见什么？	Token消耗降60%+，30+步推理稳定	跨执行知识无法积累，系统无法自我改进
Harness Engineering	我该给Agent搭什么环境？	断点续传（15步失败→30秒恢复），进化闭环	单体Agent无法承载组织级复杂任务
Loop Engineering	我该设计什么循环让Agent自主跑？	任务自动触发/执行/验证/迭代	不能自设计循环、不能与其他Loop对话、不能质疑目标
Agent OS / Graph	认知与执行如何分离与编排？	五层架构成认知操作系统，治理闭环	元认知（知道自己不知道）仍在建设中

关键洞察：每一层因前一层的天花板而出现，又为下一层铺路。这不是”选哪个层次好”的问题，而是你不可能跳层——没有 Context 就没有 Harness，没有 Harness 就没有 Loop。

要点 2：验证比生成重要——这是贯穿所有层的不变要素#

第二篇文章（Prompt/Harness/Loop/Graph 到底在关注什么）提炼了三个不变要素：验证、分层、治理。其中验证是最核心的。

多篇文章从不同角度论证了这一点：

从 Prompt 到 Harness 的演进文中指出，五层修复管道曾占 ToolExecutor 50% 代码，但这恰恰说明早期设计过度防御，应该从”堵错误出口”转向”开正确入口”
Claude Code 的 TAOR 循环把 Orchestrator 设计得极其”愚蠢”（约50行核心代码），但配套了 23 项 bash 安全检查、五档信任光谱、Sub-Agent 隔离——验证机制才是稳定性的真正来源
Loop Engineering 文章明确说：“实现者和验证者必须分离”——Maker/Checker 分离是无人值守的保障

实践启示：设计 Agent 系统时，不是先想”怎么让模型输出正确”，而是先想”怎么让错误在结构上不发生”——这才是从防御范式到赋能范式的转变。

要点 3：智能下沉到模型，确定性留给框架#

Claude Code 的设计哲学提供了一个非常具体的工程示范：“Orchestrator 越笨，架构越稳定”。

这背后的逻辑是：

模型会越来越强（这是确定性趋势），硬编码的脚手架应该随时间变薄而非变厚
如果每次模型升级你都加更多脚手架，说明你在对抗模型而非利用模型
工具只提供四种能力原语（Read/Write/Execute/Connect），让模型自行组合
验证机制用确定性代码而非 LLM 自判——bashSecurity.ts 做 23 项静态检查，阈值判断用 execute_code 而非 LLM

WorkBuddy 的产品视角呼应了这一点：模型决定上限，上下文与 Harness 决定上限能否稳定落地。“模型够强，剩下交给提示词”是误区——即使模型天花板够高，没有 Harness 的引导、约束和反馈，输出仍不确定。

要点 4：人机边界的后退不是消失，而是角色升级#

所有文章都在描绘同一个趋势：人的参与点在不断后退，但从未消失。

具体演进：

Prompt 阶段：人手写每一步指令（操作者）
Harness 阶段：人设计运行环境（架构师）
Loop 阶段：人定义目标和验收标准（治理者）
Agent OS 阶段：人负责方向选择、标准定义、责任承担

WorkBuddy 文章特别强调了一个危险：“The danger is stopping having an opinion when loops run autonomously”——自主循环运行时，人容易停止思考和判断，这才是真正的风险。人不是被替代，而是从操作者升级为治理者。

要点 5：名词会继续变，但本质不变#

第二篇文章的结论简洁有力：验证、分层、治理——抓住这三个要素，不管下个月又出什么新名词都能看懂。

这和第一篇文章的演进分析看似矛盾（一个说各层递进、一个说本质不变），实则互补：演进描述的是”为什么需要每一层”，本质论描述的是”每一层在做什么”——都是在搭建验证机制、做关注点分离、推动人机边界后退。Loop、Graph 不是颠覆前一层，而是在前一层基础上加新的抽象维度。

分歧与讨论#

5 篇文章在几个关键点上存在张力：

“赋能范式” vs 实际仍大量防御：第一篇文章主张从”堵错误出口”转向”开正确入口”，但 Claude Code 的实践显示 23 项安全检查、五档信任光谱、Sub-Agent 隔离等机制仍然是典型的防御式设计。这说明”赋能”不是取消防御，而是让防御从运行时修补变成结构设计——错误在结构上不发生，而不是发生后再去修。
Loop vs Harness 的边界模糊：Claude Code 的 TAOR 循环既是 Harness（运行时外壳）也是 Loop（自主执行循环）。WorkBuddy 把两者分为不同层，但实际产品中它们的边界很难划清。这可能意味着未来不会严格分层，而是融合为一个整体运行时。
“智能下沉到模型”的前提条件：这个哲学成立的前提是模型确实在持续变强。但如果模型在某些领域天花板已现（如长程推理、复杂规划），那么”变薄脚手架”的策略就需要调整——不是对抗模型，而是承认模型在某些场景需要更多确定性支撑。

与已学内容的联系#

这是第一篇学习笔记，暂无历史主题可关联。但建立坐标系后，后续主题都能找到位置：

Memory（三层记忆架构） → 属于 Context/Harness 层的核心组件
Skill（技能协议/生命周期） → 属于 Harness 的能力层，Loop 的原语之一
Tool Calling（MCP/Function Calling） → 属于 Context 的工具注入，Harness 的确定性验证手段
LangGraph（Graph Engineering） → 属于 Loop/OS 层的编排抽象
多 Agent 协作 → 属于 Agent OS 层的 Ecosystem Engineering

💡 思考题#

如果你现在要做一个 Agent 产品（比如一个代码审查助手），你会从哪一层开始设计？为什么不能直接跳到 Loop？ —— 这道题考验你对”层叠递进不可跳层”的理解。
Claude Code 的”智能下沉到模型、确定性留给框架”哲学，在你的工作场景中是否成立？有没有模型目前做不到但你需要的功能，这时候脚手架应该变厚还是变薄？ —— 这道题考验你在具体场景下的判断力。

🎯 行动项#

画出你当前工作/项目中 Agent 技术栈的层次映射图：标注你目前在哪一层（Prompt？Context？Harness？），以及往上每一层你还缺什么。这张图会成为后续学习笔记的参照框架。
精读 Loop Engineering 的五原语设计：搜索知识库中关于 Automations/Scheduling、Skills、Sub-agents 的文章，逐个原语深入理解——它们是后续多篇笔记的基石概念。

参考文章#

[从 Prompt 到 Harness：企业级 Agent 工程的完整演进之路]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_382c1f737bf1581599bb0cd609466f987307200439519008，提供了完整的四阶段演进框架和 Agent OS 五层架构）
[从 Prompt、Harness、Loop 一直到 Graph，我们到底在关注什么]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_b05a9e78f4562219291be04e81db8c807307200439519008，提炼了验证/分层/治理三个不变要素）
[AI 工程演化：从 Prompt 到 Loop，未来的方向在哪里]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_8012592c3a27bd62ea6cd7050e0936a77307200439519008，给出了四层定义、五原语和三个未来方向）
[看看 Claude Code 怎么做 Harness，这才是 Agent 工程化的真正难点]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_0de4602d2eebfc597e0fd462432723817307200439519008，提供了具体产品案例和”智能下沉到模型”的设计哲学）
[从模型到Harness：WorkBuddy如何把Agent做成可用产品]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_9add9f05b74bd2313dab8558022ae1f67307200439519008，从产品视角拆解各层角色定位和人的角色变化）

音乐

音乐