2026年AI智能体工程师：12步路线图——循环、图谱、评估、上下文与工作流（完整课程）

这是贯穿七大核心支柱的完整12步路线图，这些支柱决定了智能体能否真正运作：上下文、工具、记忆、循环、图谱、工作流、评估——每个步骤都配有经过验证的Claude工作流。

前沿模型在SWE-bench Verified测试中的表现从30%跃升至超过80%，仅用了一年时间。编程智能体的能力得到了显著且可衡量的提升。

然而仅有17%的高管表示已在公司范围内全面采用AI智能体。

关注我的Substack获取最新AI前沿洞察：movez.substack.com

智能体失败的原因在于上下文膨胀、循环无法收敛、以及无人能衡量上周的改动是否带来了任何改善。演示环境能运行顺畅，但生产环境完全是另一回事。

这就是贯穿七大支柱的12步路线图——它们区分了成功与失败，每个支柱都有其独特的故障模式、专属的Claude工作流，以及若被忽视会悄然扼杀智能体的隐患。

以下是让整个体系融会贯通的核心认知：这不是七项独立技能，而是同一项技能的七种投影。

• 糟糕的上下文会破坏循环。

• 缺乏评估的循环永远无法收敛到可信的结果。

• 缺乏评估的图谱只会放大错误而非提升吞吐量。

• 没有工作流的辅助，记忆会在会话结束时立即消散。

• 缺乏上下文管理的工具会在工作开始前就淹没上下文窗口。

这意味着无法孤立地学习这些技能——但存在依赖顺序，即先打基础，再执行，最后确保可靠性。这正是这12步的编排逻辑。

01. 上下文——读取实际加载的内容

Karpathy的比喻最为贴切：模型是CPU，上下文窗口是内存。上下文工程就是为这块内存精准填充下一步所需的内容——不多不少。

一个颠覆认知的数字：在Claude Code中，在你输入第一个字符之前，约7,850个token已被加载——包括系统提示、自动记忆、技能描述、CLAUDE.md文件及环境信息。

你的实际提示词仅约45个token。所有人优化这45个token，却从未审视那7,850个token。

/context命令可打印按类别划分的真实占用明细，显示已加载的记忆文件，并标记消耗最多token的工具调用。

需关注两个数字：记忆文件（占比过高意味着CLAUDE.md文件臃肿）和剩余空间。配合/memory命令可查看具体涉及的文件。

02. 上下文——删减与分层

Anthropic为Claude 5代产品删除了超过80%的Claude Code系统提示词，并在编程评估中未观察到性能下降。

多数上下文并非错误——而是为较弱模型编写的指导，如今只会消耗token，并迫使Claude在开始工作前协调矛盾。

两条安全删减原则：

• 按模块删除，而非逐行删除——单个句子淹没在评估噪声中，无法提供任何有效信息。

将绝对指令转化为原则：不说“永远不要写多行注释”，而说“编写与周围代码风格一致的代码——匹配其注释密度、命名习惯和惯用表达”。

固定规则给出单一答案，而原则让Claude通过阅读代码库找到正确答案。

• 存留内容应组织为树状结构，而非长卷。Anthropic的硬性指标：将项目CLAUDE.md控制在200行以内，仅包含Claude无法推断的注意事项。

其余内容转化为技能（启动时加载描述，调用时加载主体）或路径限定规则（仅在读取匹配文件时加载）。

03. 工具与MCP——智能体可触达的边界

工具是智能体接触世界的接口，其描述本身即构成上下文——这成为智能体能力与其知识成本之间的关键枢纽。

传统方法是通过示例教智能体使用工具。

当前模型下这一方式已被颠覆：示例会将Claude限制在它们描述的探索空间内。 应改用表达力强的参数设计。

例如状态枚举 pending | in_progress | completed 可完整描述生命周期而无需任何示例——类型本身就是文档。

Anthropic在SWE-bench Verified上达到顶尖水平，部分归功于对工具描述的精准优化，而非模型变更。

延迟加载优于全量加载。Claude Code仅加载MCP工具名（约120个token）——按需通过工具搜索获取模式定义。

将检索应用于工具描述而非全量加载，可提升选择准确率约三倍。

因此描述成为发现层：说明工具适用场景，而不仅仅是功能。 Claude找不到的工具等于未集成的工具。

04. 记忆——跨越窗口的存续

任何长任务终将超出单个上下文窗口。

边界处的处理是多数人未做过的决策——他们任由自动压缩猜测，随后困惑为何智能体忘记了一小时前提出的约束。

机制具体且值得记忆：项目根目录的CLAUDE.md和自动记忆会从磁盘重新注入。

但通过路径限定的规则和嵌套CLAUDE.md文件存在于消息历史中——它们会被摘要压缩，直至再次读取匹配文件才会返回。

调用的技能主体可返回，但有每技能5k、总计25k的上限，最早的内容优先丢弃并从末尾截断——因此关键内容应置于SKILL.md文件顶部。

可靠方案是最古老的计算方法：写入文件。

计划文件、进度日志、智能体运行时重写的笔记。它们不占用上下文窗口，且因存储在磁盘而能抵御压缩。

有选择地压缩——/compact focus on the auth bug 保留你选择的内容；当后续任务不依赖最近二十条消息时，/clear命令被严重低估。

05. 循环——何时终止

智能体循环的模式是：行动→观察→决策→重复。所有工程难题都存在于最后一步：它如何知道自己已完成？

任其自主判断时，模型会以两种方式失效——对未完成的工作宣布胜利，或在早已完成三轮迭代的事情上无尽空转。

两者都无法通过更优的提示词解决，因为它们是结构性问题。终止条件应存在于模型判断力之外的代码中。对于有界工作，这是测试门禁或模式检查。

对于未知规模的探索性任务，收敛模式是循环至枯竭：持续运行直到连续K轮未发现新内容。

一个细节决定成败，且几乎所有人都会首次出错：需与所有历史结果去重，而非仅与已确认的结果去重。

否则被拒绝的发现每轮重现，循环永不停歇，你便造就了一台为重复发现相同死胡同而持续付费的机器。

06. 循环——谁来验证答案

收敛循环仍会收敛到模型自身的信念。解决方案是验证器——处于模型判断力之外的独立组件，其唯一任务是尝试推翻发现。

若发现经受住验证则通过；否则永远无法抵达答案。

三种值得掌握的模式：

• 对抗性验证：为每个发现生成N个独立的怀疑论者提示词来反驳它；仅当多数通过时才保留。

• 视角多样化验证：为每个验证器赋予独特视角——正确性、安全性、可复现性——因为同质化检查永远无法捕捉的失败模式，多样性可以。

• 评审团模式：从不同角度生成N个尝试方案，并行评审打分，从最优方案综合结论，同时融合次优方案的亮点。

注意其指向：验证器是内联运行的评估——与第三层采用相同纪律，只是从按发布评估转为按结果评估。构建优秀验证器的团队会发现步骤11变得简单得多，因为他们已经明确定义了“优质”的标准。

07. 图谱——并行执行结构

多数人将智能体编写为直线流程——步骤一、步骤二、步骤三，每步礼貌等待上一步完成。随后他们注意到其中半数步骤根本无需等待。

节点是工作单元，边表示此输出供给彼输入。若无数据流动，则无边存在——等待纯属浪费。

核心结构是菱形：先扇出采集广度，再用普通代码规约，最后用单一智能体综合。

规约步骤值得强调，因为这是成本泄漏点——扁平化与去重是flatMap和Set操作，而非智能体任务。

边是免费的。将智能体用于判断，而非管道铺设。

天花板确实很高。Claude Code的动态工作流在单次运行中可协调多达1,000个并行子智能体，且编排成本为零模型token——因为这是脚本，不是对话。

正是这种架构使一个团队在六天内将约960,000行Bun运行时代码从Zig移植到Rust，且99.8%的测试套件仍然通过。

08. 图谱——结构拓扑的代价

拓扑结构不是装饰——它是你掌控延迟和开销的最大杠杆，两个选择决定主要方向。

首先是parallel()与pipeline()。parallel()屏障会让所有分支等待最慢节点完成后才进入下一阶段。

pipeline()让每个项目独立流经所有阶段——项目A可在第三阶段时，项目B仍在第一阶段。

默认使用pipeline()。 仅当某阶段确实需要同时获取所有先前结果时才使用屏障，例如跨集合去重。“感觉更整洁”不是理由；屏障延迟是真实、可衡量的时间浪费。

其次是按节点分层使用模型。每个子智能体会继承你的会话模型，除非脚本覆盖，因此大规模运行默认全部按最高层级计费。

有界、重复的节点——提取此字段、分类此工单——应使用更便宜的模型，而需要判断的合并节点保持高成本。

一百个廉价扇出节点馈送一个顶级综合节点，成本远低于平铺运行相同作业，且最终质量相当。

09. 工作流——应对会话中断

Anthropic完美诠释了这个问题：长任务是一个由轮班工程师组成的软件项目，每位新工程师上任时对前一班次毫无记忆。

仅靠压缩无法解决。即使是前沿模型在“构建claude.ai克隆版”这样的跨上下文窗口循环任务中也会失败——且以两种特定、可复现的方式失败。

首先，智能体试图一次性完成整个应用，中途上下文耗尽，给下一个会话留下半成品、无文档的功能需逆向工程。

其次，在项目后期，智能体环顾四周看到实际进展，便宣布工作完成。

两者都在编码开始前通过初始化智能体解决，该智能体运行一次并搭建环境：启动开发服务器的init.sh脚本、进度日志、初始git提交以及JSON格式的功能列表——claude.ai克隆版有超过200个条目，每个都标记为失败。

值得直接借鉴的细节：他们为该列表选择JSON而非Markdown，因为模型可证明更少错误改写JSON。

10. 工作流——每个会话仅完成一个增量

环境搭建后，每个编码会话都遵循契约：熟悉环境、选择恰好一个功能、像用户一样验证、保持代码库整洁。

“整洁”在真实团队中的含义是——无重大错误、代码有序，且下一位工程师能直接开始工作而无需清理他人遗留。

定向仪式机械但每次节省token：pwd、读取进度文件、读取git日志、读取功能列表、运行init.sh，并在修改任何内容前测试基础功能是否正常。

最后检查比听起来更重要——若无此步骤，智能体在破损应用上开发新功能只会加深问题。

关于标记完成：Claude倾向于完成修改、运行部分单元测试，便宣称完成，从未端到端检查功能。

提供真实的测试工具并要求其像人类用户一样验证——浏览器自动化、实际点击。

这一单一要求在Anthropic的实验中显著提升性能，捕获仅从代码无法察觉的错误。

11. 评估——量化而非主观感觉

突破点总是同一句话：用户反馈智能体在改动后变差，而团队除了猜测检查外无法验证。

没有评估，调试就是被动反应——等待投诉、手动复现、修复、祈祷没有其他回归。你无法区分真实回归与噪声。

起步应比你想象的更小。团队因设想需要数百个任务而拖延；从真实失败中抽取20-50个案例是极佳起点，因为早期改动具有显著效果。

从你已手动测试的内容、缺陷跟踪器、支持队列中提取案例。编写任务需确保两位领域专家能独立得出相同结论——任务中的歧义会成为指标中的噪声。

构建平衡测试集：测试行为应触发和不应触发的场景，否则你会优化出搜索一切的智能体。

有选择地组合三种评分类型：

• 代码型——快速、廉价、客观；尽可能使用。

• 模型型——针对细微差别的评分标准，与人类评分校准，理想情况下每个维度一个独立评分者，而非单一评分者评判所有内容。

• 人类型——黄金标准，谨慎用于校准其他类型。

评估智能体的产出，而非其路径：检查工具调用的精确序列很脆弱，因为智能体会经常找到你未预料的有效方法。

12. 评估——保持数字的诚实性

无人审阅的评估套件产生的数字无人可信。在查看大量试验的记录之前，你不会知道评分器是否有效—— 当任务失败时，记录会告诉你智能体犯了真实错误还是你的评分器拒绝了有效解决方案。

失败应显得公平：明确问题所在及原因。

两个陷阱会让优秀智能体显得糟糕。

• 多次试验中0%通过率通常意味着任务有缺陷，而非智能体无能。 Opus 4.5在CORE-Bench上初始得分42%——随后研究人员发现评分机制过于僵化（如期望“96.124991…”时拒绝“96.12”）、规格模糊及不可复现的任务。修复后达到95%。

• 相反陷阱是饱和——100%的评估只能追踪回归，但不提供攀登空间，真正的能力增益开始表现为噪声。

然后区分两个指标。pass@k 是k次尝试中至少一次成功的概率——随k增加而上升。pass^k 是k次全部成功的概率——它快速下降。单次75%通过率时，三次全部通过仅约42%。

单次成功足够时使用pass@k；对任何面向客户的场景使用pass^k，因为用户期望每次都能正常工作。

最后，使其制度化。将评估套件接入CI，确保每次改动和模型升级都运行。

这能将新模型发布从数周手动测试转变为一天内运行套件并阅读差异——这是没有评估的团队永远无法追上的复合优势。

七大支柱对应Claude实践任务

• 查看你从未检查的窗口。先度量，后删减。记忆文件数字过高意味着CLAUDE.md臃肿——一条命令诊断，一个下午修复。

› /context 接着 /doctor

• 审计你的工具描述。每个描述都应说明工具适用场景，而不仅是功能。这句话是发现层——缺失它，已连接的工具等于Claude永不选用的工具。

› 审查此MCP服务器中的所有工具描述。为每个工具添加“使用场景”语句，并精简参数类型。

• 将状态移至文件系统。让Claude维护一个运行中不断重写的计划文件。它因存储在磁盘而能抵御压缩…