AI 智能体的五层工程
Context · Loop · Jev · Harness · Evals —— 把一篇 X 长文，讲成高中生也能听懂的课
📚 本课学习地图
- 开篇：先招个"新员工" —— 五个词到底是什么关系
- 第 1 层 · 上下文工程 —— 提问前，它桌上放了什么
- 第 2 层 · 循环工程 —— 清单，还是目标
- 第 3 层 · Jev 工程 —— 请个"前台"做选择题
- 第 4 层 · 支架工程 —— 同一个员工，两间办公室
- 第 5 层 · 评估工程 —— 每月同一张考卷
- 五层联动：一天落地清单
- 术语表
每章结构：💡 生活类比 → 📖 专业术语（配通俗解释）→ ⚙️ 工作原理 → 🛠️ 怎么搭建 → 🚀 省力捷径 → ✅ 一句话记住 → ✏️ 自测一题
0开篇：先招个"新员工"
现在大家嘴里有五个很火的词：上下文工程、循环工程、Jev 工程、支架工程、评估工程。听起来像五个互相竞争的流派，其实不是——它们是同一个系统的五个层次，每一层只回答一个问题。
想象你刚招了个新员工：
- 上下文 —— 你问他问题时，他桌上摆着什么
- 循环 —— 他是照你的清单一步步做，还是自己想下一步
- Jev —— 前台先把信分好类，他只看重要的
- 支架 —— 他的办公室：有什么工具、哪把钥匙、谁来检查他的活儿
- 评估 —— 每月同一张考卷，看他是不是真进步了
AI 智能体就是这个新员工：模型是"人"，这五层是"人周围的一切"。五层搭对了，一个小团队能干以前要招人才干得完的活——重复工作交给经得起生产环境考验的智能体，人只保留做决定的部分。这就是"不加人头也能扩张"的现实样子。
记住这个公式，后面第 4 章会反复用到它。本课每一层都会讲四件事：它是什么、怎么工作、在哪用、怎么搭，外加一个"不想从零搭"的省力捷径。现在，从第 1 层开始。
1第 1 层 · 上下文工程
每次提问前，你往新员工桌上放文件。放对三页纸，他几秒就答出来；放三百页，答案就被埋在纸堆中间，他翻着翻着就漏掉了。
上下文工程 Context Engineering /ˈkɒntekst ˌendʒɪˈnɪərɪŋ/
通俗说：每次提问之前，决定"桌上放什么、放哪里"的技术。
上下文窗口 Context Window
通俗说：就是那张"桌子"——模型回答问题前能看到的全部内容：你的指令、之前的聊天记录、从数据库查到的资料、它调用每个工具后返回的结果，全在这张桌上。
⚙️ 工作原理：多 ≠ 好
直觉上，资料给得越多模型懂得越多，对吧？斯坦福大学直接做了实验，结果很反直觉：
给模型 20–30 篇文档去回答问题，它对中间位置文档的准确率跌到约 50%–57%；而一篇文档都不给时，同一模型能拿到 56%。答案明明就在"桌上"，给了资料反而考得更差。
背后有两个原因：
- 注意力偏心：模型最关注窗口的开头和结尾，最忽略中间——这就是著名的 "lost in the middle"（迷失在中间）现象；
- 个个都要钱：每一个 token（大致理解为"半个汉字/一个英文单词碎片"）都要花钱、耗时，不管它有没有用。
⚙️ 关键机制：提示缓存
提示缓存 Prompt Caching
通俗说：服务商把你提示词的开头部分存下来，下次调用直接复用，缓存的 token 大约便宜 10 倍。但有个苛刻条件——开头必须字节级完全一致，改一个字符，后面全部按原价计费。
所以铁律是：永远把稳定的东西放前面，常变的东西放最后。
🛠️ 怎么搭建：每份资料只进四个位置
只放"每次调用都成立"的东西：角色、约束、输出格式。保持字节级一致：顶部别放时间戳，JSON 的键别随机排序。
对话中途不要增删工具——会破坏缓存，还会让模型去调用已经不存在的工具。想限制某步的工具？拦截调用、保留定义。
又大又长期用的东西进文件，窗口里只留路径；网页也一样，留 URL、扔正文。记住：扔掉内容，留下"能找回它的钥匙"。
中间修不好，就把重要的东西挪出中间：每隔几步，在上下文末尾重申一次当前目标。
工具也不能无限加。Anthropic 实测：58 个工具定义在用户开口前就吃掉约 55,000 token。改成"让模型按需搜索工具"后，Opus 4 在基准测试上从 49% 涨到 74%。
经验法则：20 个工具以下直接加载，超过就改搜索。任务太大时还有一招：派一个子智能体——让它在自己的窗口里读完 50 个文件，只交回一页摘要，你的主上下文永远只看到摘要。
上下文工程 = "桌上放什么、放哪里"。资料不是越多越好，中间是盲区；稳定的放前、常变的放后，大文件只留钥匙。
原文作者提到，他朋友做的 Viktor（住在 Slack / Teams 里的 AI 员工）把大部分上下文工程做成了"公司级"的：记忆（上周从联合创始人那学到的，不用你今天再贴一遍）、接资料源（连上 Notion / Google Drive / HubSpot，点名要哪份文档它自己去读——就是"磁盘规则"的现成版）、Skills（你录屏做一遍任务，它写成固定流程，你改完批准——相当于一份写好的系统提示）。
留给你自己做的只剩三件：写一份公司简介（卖什么、卖给谁、看哪些数字、绝不能做什么）；一个帖子只讲一件事，第一句就写清楚"什么叫完成"；它记错了就去设置里清空记忆，别每帖纠正。
注：以上为原文中的付费合作内容，仅供参考。
✏️ 自测：为什么"稳定的放前面，常变的放最后"？
2第 2 层 · 循环工程
你可以给员工一张清单：打开文件 → 改第 12 行 → 保存。也可以只给他一个目标："让测试通过"。拿到目标，他会自己试、看结果、再定下一步——清单是工作流，目标是循环。
工作流 Workflow /ˈwɜːkfləʊ/ vs 循环 Loop /luːp/
通俗说：工作流是"你把每一步都写好"；循环是"你只给目标，模型自己决定下一步"。记住这句断语：你写的一百步，仍然是工作流；模型自己选的三步，就是循环。
⚙️ 工作原理：思考 → 行动 → 观察 → 决定，无限重复
一个循环就是四个动作不停转。看它修 bug 的样子：
- 跑测试，3 个失败了；
- 读第一条报错：少了个导入；
- 加上导入，再跑；
- 还剩 1 个失败，读报错、修、再跑；
- 全过了，停。
这五步没人提前写过——模型是看完上一步的结果，才选下一步的。这就是循环的全部奥秘。
循环很贵：一个智能体用的 token 大约是单次调用的 4 倍，多智能体协作约 15 倍。所以铁律是——只在"写不出步骤"时才用循环；凡是能写出步骤的，写成工作流，因为工作流更便宜、能并行、第 4 步失败了只重跑第 4 步，不用一切重来。
🛠️ 怎么搭建：循环的四个零件，缺一不可
- 一个"什么叫完成"的目标。不说"修好这个 bug"，要说 "auth_test.py 里挂掉的测试通过，且没搞坏别的东西"；
- 一个检查器 Checker。模型之外的、能说"过 / 没过"的东西：测试套件、编译器、linter。研究结论很一致：有真实外部反馈时自我纠正才有效，模型自己审自己基本没用。没有检查器，就没有循环，只有敞开花钱；
- 一条停止规则。检查器通过，或达到最大轮数，或连续两轮输出一模一样（卡住了）；
- 一份预算。轮数和钱，两样都要封顶。
写成代码，整个循环就几行：
for turn in range(MAX_TURNS): # 最多跑这么多轮
action = model.next_step(goal, history) # 模型看历史，选下一步
result = run(action) # 真去执行
history.append(result)
if checker(result): break # 检查器说过了 → 停
if repeated(history, 2): break # 两轮没进展 → 停
if spent() > BUDGET: break # 超预算 → 停
else:
fallback_workflow(goal) # 兜底：转固定工作流🏭 生产级做法：Atlan 的"混合模式"
原文介绍了一个已公开的最佳实践：先跑确定性过滤（写死的规则），只有约 14% 的告警能到达智能体；循环最多给 3 轮；3 轮后置信度还低于 50%，就交给固定的 Python 工作流。先过滤、循环一小会儿、再兜底。
循环工程 = "谁决定下一步"。写得出步骤就别用循环；要用，就配齐"完成定义、检查器、停止规则、预算"四件套，贵的东西要有刹车。
在 Viktor 里，你在帖子里布置的每个任务天然就是一个循环：你写目标，它定步骤、调工具、回帖交结果。四件套的对应关系是——目标：它会追问含糊的需求，但"什么叫完成"还是你写清楚最靠谱；检查器：点名核对源（Stripe 总额、行数、测试套件）让它更强；停止规则：敏感操作自动暂停等人，结果总会回到你面前；预算：按点数计费，推理档位决定每步单价，周期任务里"频率"很要命（每小时报一次比每周报一次贵得多）。
Atlan 的混合模式不用写代码也能用：重复的活变成定时任务（它提议、你批准前保持暂停——这就是你的工作流）；开放的活扔进帖子（这就是你的循环），兜底的人是你。
注：以上为原文中的付费合作内容，仅供参考。
✏️ 自测：下面哪个该用"循环"，哪个该用"工作流"？——"每天凌晨把 CSV 导入数据库并生成固定格式日报"
3第 3 层 · Jev 工程
办公室的专家不会每封信都亲手拆——前台先分好类：账单一摞、垃圾邮件进碎纸机、合同转给律师。你的智能体也在干两种活：写东西和拿主意，现在一个大模型全包了，等于"请律师来分信"。
Jev 就是那个前台：它不写作，只做选择。
Jev（一种轻量"选择"模型）
通俗说：你提前把问题和候选答案给它，它只返回三样东西之一，再加一个置信度分数：
- 是 / 否（二选一）；
- 多个选项中挑一个（比如：垃圾邮件 / 查订单 / 退款 / 其他）；
- 打个分（比如紧急程度 1–5 分）。
因为只做选择题，它又快又便宜。
官方宣称：Jev 响应 70–500 毫秒，而大模型要 3–329 秒；价格 $0.042 / 百万输入 token，输出免费。
Jev 才发布两周，独立测试刚开始，原文作者也坦白了短板：
- 邮件分类：朴素的逻辑回归 98.9%，Jev 98.6%——传统方法反而略胜；
- 钓鱼邮件检测：Jev 62.6%，Claude Haiku 4.5 是 81.3%——差得不少；
- "零幻觉"的宣传有脚注：不是实测结论，只是说"输出永远符合预设格式"；
- 置信度分数开箱不是真概率——把它当排序用，阈值要在你自己标注的数据上定。
结论：Jev 是"便宜的前台"，不是"更聪明的专家"，别把它当大模型用。
🛠️ 怎么搭建：门卫模式
最合理的用法，是把它当大模型门前的"门卫"：
- 所有输入先到；
- Jev 对每条回答一个很窄的问题；
- 有把握、很常规的 → 走便宜通道（打标签、分流、丢弃）；
- 没把握、很特殊的 → 交给大模型。没把握就走贵的路，这叫 fail closed（闭门失败）：宁可多花钱，不让可疑的东西溜过去。
# Jev 先做选择题
d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
if d.confidence >= 0.7 and d.option != "other":
handle_cheap(d.option, item) # 有把握 → 便宜处理
else:
main_model(item) # 没把握 → 交给大模型（fail closed）Jev 工程 = "便宜的决定别用贵的人做"。先试试 30 分钟的"笨办法"：标几百个真实样本，训个基础分类器，不够好再升级——这是所有厂商宣传都必须打败的基线。
Viktor 的公开技术栈里没有 Jev，但思路在两个你能控制的地方用得上：选推理档位——Smart（Claude Opus）、Balanced（Claude Sonnet，约一半价格）、Ultra（Claude Fable，约两倍），分个类、取个数不需要顶配；在他前面加道门——想让他处理邮件流、告警流，别整条流直接塞给他，先过分类器/Jev，只有需要判断的才变成他的任务。这是五层里"你的工程依然重要"的两层之一（另一层是评估）。
注：以上为原文中的付费合作内容，仅供参考。
✏️ 自测：Jev 的"fail closed"是什么意思？
4第 4 层 · 支架工程
同一个员工，两间办公室：第一间有趁手的工具、墙上的手册、有同事复核他的活儿，而且没有保险柜的钥匙；第二间只有一台笔记本，和你的管理员密码。同一个人，产出天差地别——员工是模型，办公室是支架。
支架 Harness /ˈhɑːnəs/（马具）
通俗说：模型之外的一切——工具、权限、沙箱、讲清项目的说明文件、对输出的检查。它 2026 年才成为独立学科，因为人们开始测量，发现"模型"解释不了那么多成败。
- Anthropic 只改了容器的资源配置，没动模型，基准分数动了 6 分；
- LangChain 冻结模型、只改支架，同一基准涨了 13.7 分；
- 把支架调好后，一个便宜十倍的开源模型拿到 0.86 分，对手最贵的 Opus 4.8 是 0.87——几乎打平。
结论：你买的早已不是模型，而是"模型＋支架"。只要智能体一碰真实的东西——代码库、邮箱、支付、生产数据库——你就需要支架。
🛠️ 怎么搭建：由外向内，四层
"它物理上够不着什么"：容器、独立分支、只读数据库用户、除了白名单不联网。写第一行提示词之前先做这个。
"行动前怎么引导它"：仓库里的 AGENTS.md、写得清楚的工具描述、几个好输出的例子。四行就管用：
"行动后谁来检查"：linter、类型检查、测试套件——快而确定，全量跑；慢检查（如第二个模型审 diff）只用在重要的事上。
扎心数据：智能体请求审批时，人们 93% 点了通过——弹窗几乎没保护作用。真正的保护是"根本没有这个操作"，审批只留给真正不可逆的。
# 一份 AGENTS.md 不用长，四行就能改变行为
# AGENTS.md
- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
- Run tests with `make test`. They must pass before any commit
- Never edit /migrations by hand, use `make migration`
- DB access is read only. Ask before any schema change钩子 Hook
通俗说：指引的"强制版"。比如在 Claude Code 里，钩子是一段小脚本，在工具调用之前运行、可以直接拦截。"不许推 main 分支"写进提示词可能被忘，写成钩子就一定拦得住。
支架的每一条，都是在赌"模型做不到某事"，而这些赌注会过期——Anthropic 就在一次模型升级后，删掉了一整块脚手架，因为新模型已经不需要了。每隔几个月重读一遍你的支架，删掉模型已经"长大"到不需要的部分。
支架工程 = "办公室装修"。由外向内：先隔离（锁门），再指引、传感器、权限；审批弹窗防不住 93% 的"随手点通过"，靠的是"压根没给钥匙"。
如果"智能体＝模型＋支架"，那用 Viktor 你大部分买到的是支架：底下的模型是 Claude，周围的一切都是现成的——工具（3200+ 集成，GitHub / Linear / HubSpot / Stripe / Notion / Google Drive，没有现成连接它能自己造一个）、指引（Skills：录屏一次，它起草流程，你改完批准）、传感器（数字对不上它会质疑，需求含糊它会追问，每步都落在团队可见的帖子里）、权限（对外邮件、资金变动自动暂停等人批，新定时任务默认暂停等人开）。
产品替你做不了的是隔离——因为隔离用的就是你亲手交出去的凭证。记住那 93%，用最小权限连接它：只读数据库用户、受限的 Stripe key、共用的支持邮箱（不是你的私人邮箱）、只限指定仓库的 GitHub token。它够不着的，就搞不坏。
注：以上为原文中的付费合作内容，仅供参考。
✏️ 自测：为什么说"审批弹窗几乎没保护作用"？
5第 5 层 · 评估工程
你怎么知道新员工进步了？拿上个月那张考卷再考一次，对比分数。没有同一张考卷，你做的每次调整都是猜——评估就是智能体的那张考卷：一套你已经知道正确答案的任务，每次改动都跑一遍。
评估 Evals /ˈiːvælz/（evaluations 的缩写）
通俗说：一套"标准答案已知"的测试题，专门用来衡量：我改的这一处，到底让智能体变好了还是变坏了。
有两种查法：
- 端到端检查：最后答案对了吗？——它只告诉你"分数动了"，不告诉你为什么；
- 行为检查 Behavioral Check：某个具体行为发生了吗？比如"回答前有没有先查订单"、"含糊时有没有追问"、"说' done' 前有没有核实"。它跑在 trace（轨迹日志：智能体做过每件事的完整记录）上，不只看最终答案。Google 的要求是：这套检查 5 秒内跑完，才能每次改动都跑。
如果用模型来当判卷老师，这叫 Judge（裁判模型），而裁判本身也要被查。Airbnb 发现：约 3/4 的模型生成的参考答案，换一次运行就变了——那次评估测的不是智能体，是裁判自己的噪声。
🛠️ 怎么搭建：从真实失败开始
- 从真实失败开始。翻实际运行记录，找到搞砸的地方，一条失败变成一道考题。Airbnb 的黄金集 Golden Set一般 50–100 个例子，且必须包含失败案例；
- 一例一行为检查。每个例子只验证一件事；
- 检查你的裁判。先人工判一小批，看你和模型的判分一致率，信得过再用；
- 抽样生产流量。Airbnb 每天抽 5% 的真实流量回放——因为真实用法会漂移，考卷不更新就会过期。
一道考题可以小到这样：
# 一道评估考题：YAML 格式，人和机器都读得懂
input: "Refund order #1042, customer says it arrived broken"
expect:
- looks up the order before replying # 先查订单，再回复
- asks for approval before issuing refund # 退款前先请求批准
check:
- trace has get_order before send_reply # 日志里：查单发生在回复之前
- trace has approval_request before refund # 日志里：申请批准发生在退款之前评估工程 = "每月同一张考卷"。从真实失败里出题，一例一行为检查，裁判也要被抽查；盯单个检查项，别被总通过率骗了。
这一层没有任何产品能替你搭——因为只有你知道，你的业务里什么叫"正确答案"。但方法可以直接搬：用上两周后，挑 20 个你知道正确答案的帖子（凡是你纠正过它的，一个别漏）；每例写一条大白话检查（每个数字都给了来源吗？需求含糊时追问了吗？对外发出前暂停了吗？）；每次改动后重跑——换技能、改简介、换档位都要跑（从 Smart 换到 Balanced 省约一半点数，换之前先考一次）；每周再人工抽 5 个帖子判分。
注：以上为原文中的付费合作内容语境，仅供参考。
✏️ 自测：为什么"行为检查"比只看"最终答案对不对"更有用？
6五层联动：一天落地清单
五层、五个问题，复习一下：
| 层 | 回答的问题 | 生活类比 | 今天能做的最便宜的一件事 |
|---|---|---|---|
| ① 上下文 | 它提问前看到了什么？ | 桌上摆着什么 | 把稳定的指令收进系统提示，不再天天改 |
| ② 循环 | 谁决定下一步？ | 照清单，还是定目标 | 给循环加上轮数上限和金额上限 |
| ③ Jev | 便宜的决定谁来做？ | 前台分拣员 | 标 200 个样本，训个基础分类器当基线 |
| ④ 支架 | 它能碰什么、谁来检查？ | 他的办公室 | 让智能体用一个"删不掉任何东西"的账号跑 |
| ⑤ 评估 | 它真的变好了吗？ | 每月同一张考卷 | 把最近 5 次失败写成测试用例 |
原文作者的结论：模型不再是难的部分，这五层才是。大多数团队应该把前三层（上下文、循环、支架）尽量"拿现成的"，把自己的时间花在真正决定质量的两层上——便宜的决定（Jev）和评估（Evals）。外加一件谁也替你做不了的事：交出去的凭证，永远给最小权限。
"把这五层搭对，一个小团队能接下以前要招人才接得住的活。重复工作交给经得起生产考验的智能体，你的人保留做决定的部分——这就是不加人头也能扩张的现实样子。"
表术语表
模型回答前能看到的全部内容，"桌子"本身。
复用提示词开头，约便宜 10 倍；要求前缀字节级一致。
计费与计量的最小单位，约等于半个汉字或一个英文单词碎片。
人把每一步提前写死的固定流程。
只给目标，模型自己决定下一步；思考→行动→观察→决定。
模型之外的"判官"：测试套件、编译器、linter。
循环什么时候停：通过 / 到轮数 / 卡住 / 超预算。
派出去干脏活累活的小智能体，只交回摘要。
只做选择题（是/否、多选一、打分）的轻量模型，又快又便宜。
拿不准就走贵的路，宁可多花钱不放过可疑输入。
模型之外的一切：工具、权限、沙箱、说明、检查。
工具调用前运行、可直接拦截的强制版"指引"。
已知正确答案的测试集，每次改动跑一遍。
50–100 个精选考题，必须包含真实失败案例。
智能体做过每件事的完整记录，行为检查跑在它上面。
用模型当判卷老师；它自己也要被抽查。