AI Agent 的五个层级：从 Prompt 到生产环境

现在大家聊起 Agent，总绕不开五个词：Context engineering、loop engineering、Jev engineering、harness engineering、eval engineering。

听起来像是五种互相竞争的方案，其实不是。它们是同一个系统的五层结构，每一层只回答一个问题。

最简单的理解方式，是想象你刚招了一位新员工：

• Context —— 你找他办事时，他桌上摆着什么
• Loop —— 他是照着你的清单做，还是自己判断下一步该干嘛
• Jev —— 前台帮你分拣信件，让他只看最重要的东西
• Harness —— 他的办公室。有什么工具、拿着什么钥匙、谁来检查他的工作
• Evals —— 每个月同一套考题，这样你才知道他是不是真的进步了

AI Agent 就是这位员工。模型是人本身，而这五层就是他周围的一切。把这五层搭好，一个小团队就能接下以前必须靠招人才能干的活。重复性的工作交给能在生产环境里稳定跑起来的 Agent，你的人只管做决策。这就是“不加人也能扩产能”在现实中的样子。

接下来我会逐层拆解：它是什么、怎么运作、用在哪里、怎么搭建。

每一层我还准备了一个“捷径”——不用从零开始造轮子，新手也能轻松拿到同样结果的简单方法。这些捷径是我的朋友 Viktor 帮我一起整理的。

Viktor 是一个住在你 Slack 或 Microsoft Teams 里的 AI 员工。他和所有人待在同一个频道里，像个真正的队友一样干活——一个不需要开新 HC 就能直接进组的队友。

和他协作的感觉，就像和一个真人共事：

• 你在频道或话题串里 @ 他，描述一下任务。
• 他自己理清步骤，跨工具把活干完，然后把结果发回同一个话题串里。

配置也很简单。只要把 Viktor 加到你的工作区，他就会像其他团队成员一样出现在参与者列表里。如果你想边看文章边试试他，可以用优惠码 YARCHI100。

图 1. Agent 的五层结构

1. Context engineering

定义

每次提问前，你都会在员工桌上放一叠文件。放上最关键的三页纸，他几秒钟就能答出来；堆上三百页，答案就被埋在中间，他根本找不到。

模型就是员工，办公桌就是上下文窗口（context window）：模型在回答之前看到的所有内容。你的指令、此前的对话记录、从数据库拉出来的文档、每个工具执行后的输出，全都在里面。

Context engineering 就是决定往桌上放什么、放在哪。

运作原理

上下文越多，不代表答案越好。超过某个临界点，反而会变差。

Stanford 直接做过测试：给模型 20 到 30 份文档，它对中间部分文档的准确率会掉到 50% 到 57% 左右。而一份文档都不给的时候，同一个模型的得分是 56%。答案明明就在窗口里，模型的表现却比什么都不给还差。

原因有两个：

• 模型对窗口的开头和结尾注意力最强，对中间部分最弱。
• 每个 token 都要花钱花时间，不管它有没有用。

这里唯一值得掌握的机制是 prompt caching（提示缓存）。服务商会存下你 prompt 的开头部分，下次调用时直接复用，而缓存 token 的成本大约只有全新 token 的十分之一。

但有个坑：只有当开头部分逐字节完全一致时，缓存才会生效。只要前面改了一个字符，后面的内容就全部按原价计费。所以顺序永远是：稳定的内容放前面，会变的内容放最后。

怎么搭建

所有上下文都归入四个位置之一：

1. System prompt。 只放每次调用都不变的东西：角色、约束条件、输出格式。保持逐字节一致。别在开头塞时间戳，也别让 JSON key 随机乱序。
2. Tools。 别在对话中途增删工具。这会破坏缓存，还会让模型去调用已经不存在的工具。如果某一步想限制某个工具，拦截调用就行，保留定义。
3. Disk。 任何体积大或长期存在的内容都放进文件，窗口里只留路径。网页也一样：留 URL，丢掉正文。丢掉内容，只留能把它取回来的 key。
4. Tail。 每隔几步，在上下文末尾重申一次当前目标。中间部分你控制不了，所以别让重要的东西待在那儿。

工具数量也有上限。Anthropic 测过，58 个工具定义在用户还没打一个字之前，就会吃掉大约 55,000 个 token。让模型去搜索工具，而不是一次性全加载进来，Opus 4 在他们基准测试上的表现从 49% 提升到了 74%。

20 个工具以内，保持全量加载；超过这个数，换成搜索模式。

处理大任务还有一个技巧：派一个 sub-agent 出去。它在自己的窗口里读完 50 个文件，交回一页纸的摘要。你的主上下文永远只看到这页摘要。

图 2. 一次模型调用里装了什么

捷径

Viktor 把这些脏活累活基本都替你干了，因为他的上下文是公司级别的。

• Memory。 他在整个团队范围内持续记住你的业务信息。上周他从你联创那里学到的东西，今天不需要你再粘贴一遍。
• Connected sources。 接上 Notion、Google Drive 或 HubSpot 之后，你就不用再往聊天里贴文件了。说出文档名或记录名，他自己去读源文件。“Disk 原则”直接帮你落地了。
• Skills。 你录屏演示一次操作，他把录像转成书面流程，你修改、确认。从此这条指令就是固定且经过审核的，就像一个写得很好的 system prompt。

你需要做的只剩这些：

• 写一份简短的公司说明，一次就够：卖什么、谁买、哪些指标重要、绝对不能做什么。
• 一个话题串只做一件事，第一条消息就说清楚什么叫“做完了”。
• 如果他学错了什么，去设置里清空记忆，而不是在每个话题串里反复纠正他。

2. Loop engineering

定义

你可以给员工一张清单：打开文件，改第 12 行，保存。也可以给他一个目标：让测试通过。

有了目标，他会先试一下，看看发生了什么，再决定下一步干什么。清单是 workflow（工作流），目标是 loop（循环）。

运作原理

一个 loop 就是四个动作不断重复：思考、行动、观察、决策。修 bug 的过程长这样：

1. 跑测试。三个失败。
2. 看第一个报错。缺 import。
3. 补上 import，再跑一次。
4. 还有一个测试没过。看报错，修掉，再跑。
5. 全过了。停。

没人提前写好这些步骤。模型是看到上一步的结果后，才选出下一步的。

这就是全部区别。你写的一百步依然是 workflow；模型自己选的三步就是 loop。

只有当你没法提前写出步骤时，才用 loop。能写就写。Workflow 更便宜、能并行，而且第四步出错时，你只需要重跑第四步，不用从头来。

Loop 也很贵。一个 Agent 消耗的 token 大约是单次调用的四倍。多 Agent 架构大概是十五倍。

怎么搭建

一个 loop 需要四个部分。少任何一个都会跑不起来：

1. 一个有明确“完成标准”的目标。 不是“修 bug”，而是：“auth_test.py 里失败的测试通过了，而且没搞坏别的东西。”
2. 一个 checker。 模型之外的东西来判定 pass 或 fail：测试套件、编译器、linter。关于 self correction 的研究结论很一致：有真实的外部反馈才有效，让模型自己审自己就会翻车。没有 checker 就不叫 loop，只是无底洞式烧钱。
3. 一条停止规则。 checker 通过了，或者达到轮次上限，或者连续两次输出一模一样。
4. 一个预算。 轮次要限，钱也要限。

写成代码，也就几行：

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # 完成了
7    if repeated(history, 2):  break   # 卡住了
8    if spent() > BUDGET:      break   # 太贵了
9else:
10    fallback_workflow(goal)

我见过公开的最佳生产方案是混合式的。Atlan 会先跑一层确定性过滤，只有大约 14% 的告警能真正到达 Agent。

然后 loop 最多跑三轮。三轮之后置信度还低于 50%，就交给固定的 Python workflow 接管。

先过滤，短循环，兜底。

图 3. 如何在工作流和循环之间做选择

捷径

你在话题串里交给 Viktor 的每一个任务，都是一个 loop。你写目标，他选步骤，跨工具执行，然后带着结果回到话题串。

四个部分对应如下：

• Goal。 需求不完整时他会反问，而不是瞎猜。但你依然要写清“完成标准”。“上周营收报告，总数和 Stripe 对得上，周一早上 9 点前发到 #finance”绝对比“做个报告”强。
• Checker。 发布前他会标出看起来不对劲的数字。你可以让它更强：指定核对依据，比如 Stripe 总额、行数、测试套件。
• Stop rule。 敏感操作会暂停等你人工确认，结果也一定会回到你手上。
• Budget。 额度。推理档位决定了每一步的价格，而对周期性任务来说，频率很关键。每小时一次的报告比每周一次贵得多。

Atlan 那种混合方案不写代码也能实现。重复性工作变成定时任务：他提出来，但在你批准之前一直暂停。这就是你的 workflow。

开放式任务丢进话题串，那就是你的 loop。你就是那个兜底方案。

3. Jev engineering

定义

办公室里的专家不会亲自拆每一封信。前台会先把邮件分好类：账单一堆，垃圾扔掉，合同转给律师。

你的 Agent 做两类事：写东西，以及做判断。现在一个大模型两样全包，等于你花律师的钱让人去分拣信件。

Jev 就是前台。它从不写东西，只做选择。

运作原理

你提前把问题和可选答案给 Jev。它返回三样东西之一，外加一个置信度分数：

• yes 或 no
• 从一组选项里挑一个
• 量表上的一个数值

因为它只做选择，所以又快又便宜。官方宣称的数据是 70 到 500 毫秒，对比别人的 3 到 329 秒；每百万输入 token 0.042 美元，输出免费。

说句实话：Jev 才出来两周，独立测试刚刚开始。

• 在邮件分类上，普通逻辑回归拿了 98.9%，Jev 是 98.6%。
• 在钓鱼检测上，Jev 62.6%，Claude Haiku 4.5 是 81.3%。
• “零幻觉”这个数字附带作者自己的脚注：这不是实测结论，只是说输出始终符合 schema。

置信度分数开箱也不是真正的概率。把它当成排序依据，用你自己的标注数据去定阈值。

怎么搭建

合理的做法是在昂贵模型前面加一道门：

1. 所有请求先进来。
2. Jev 针对每条请求回答一个狭窄的问题。
3. 高置信度 + 常规情况：低成本处理。打标、路由或直接丢弃。
4. 拿不准或不常见：交给主模型。

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # 默认走保守路线：拿不准就走贵的路径

在做这些之前，先试最简单粗暴的办法。标几百条真实样本，训一个基础分类器，不够用再往上升级。

这活儿半小时就能干完，而且是任何厂商宣传都必须打败的基线。

图 4. Jev 回答的三类问题

捷径

Jev 不在 Viktor 已公开的技术栈里，但这个思路可以用在你自己能控制的两个地方：

• 推理档位。 他有三档：Smart 跑 Claude Opus，Balanced 跑 Claude Sonnet（成本约一半），Ultra 跑 Claude Fable（成本约两倍）。分拣请求或提取一个数字，根本用不上最高档。
• 他前面的那道门。 如果你想让他处理客服邮件或告警这类数据流，别把整条流都丢给他。先加个分类器或调一次 Jev，只有真正需要判断的请求才变成他的任务。

这是即使用了 Viktor，你自己的工程能力依然很重要的两层之一。

4. Harness engineering

定义

同一个员工，两间办公室。第一间里他有趁手的工具、墙上的操作手册、帮他复核工作的同事，但没有保险柜钥匙。第二间里他只有一台笔记本和你的管理员密码。

技能一模一样，结果天差地别。员工是模型，办公室就是 harness。

Agent = 模型 + harness。

运作原理

Harness 就是模型之外的一切：工具、权限、沙箱、解释项目的文件、对输出的校验。

它在 2026 年成了一门独立学科，因为大家开始量化评估，发现模型的作用比想象中要小：

• Anthropic 只改了容器资源，基准分数就涨了 6 分。
• LangChain 锁死模型，只改 harness，同一个基准涨了 13.7 分。
• 接着他们用一个便宜十倍的开源模型调优 harness，做到了 0.86，对标 Opus 4.8 的 0.87。

你现在买的不再只是一个模型，而是模型加 harness 的组合。

只要 Agent 碰到真实世界的东西——代码仓库、收件箱、支付、生产数据库——你就需要一个 harness。

怎么搭建

由外向内搭：

1. Containment（隔离）。 Agent 物理上碰不到的东西。容器、独立分支、只读数据库账号、除白名单外断网。在写第一个 prompt 之前就把这事做了。
2. Guides（指引）。 行动前引导它的东西。仓库里的 AGENTS.md 文件、清晰到能让模型选对的工具描述、几个优秀输出的示例。
3. Sensors（传感器）。 行动后检查它的东西。Linter、类型检查、测试套件：又快又确定，所有输出都跑一遍。慢一点的检查，比如用第二个模型 review diff，只在关键地方跑。
4. Permissions（权限）。 Agent 请求审批时，人有 93% 的概率会直接批。审批弹窗几乎起不到保护作用。真正的保护是那些根本不可用的操作。把审批留给极少数真正不可逆的事情。

指引文件不用写太长。四行就足以改变行为：

1# AGENTS.md
2- Monorepo：/api (FastAPI)、/web (Next.js)、/jobs (cron)
3- 用 `make test` 跑测试。提交前必须全部通过
4- 禁止手动编辑 /migrations，用 `make migration`
5- DB 访问为只读。任何 schema 变更前必须先申请

Hooks 是同一种思路的强制版。在 Claude Code 里，hook 是一段在工具调用前运行的小脚本，可以直接拦截调用。“禁止 push 到 main”应该做成 hook，而不是 prompt 里的一句话。

提醒一句：harness 的每一部分，都是在赌模型做不到某件事，而这些赌注是有保质期的。Anthropic 在一次模型升级后，直接删掉了一整套脚手架组件，因为用不上了。

每隔几个月重新审视一遍你的 harness，删掉模型已经不再需要的部分。

图 5. Harness 的四道防线

捷径

如果 Agent = 模型 + harness，那你在 Viktor 身上得到的大部分东西都是 harness。底层模型是 Claude，模型周围的一切都准备好了：

• Tools。 3,200+ 集成：GitHub、Linear、HubSpot、Stripe、Notion、Google Drive 等等。遇到没有现成连接的工具，他能自己搭一个。
• Guides。 Skills。不用你自己写 AGENTS.md，你录个屏，他起草流程，你来修改。
• Sensors。 他会标出对不上的数据，质疑缺失信息的需求。每一步都会落在团队可见的 Slack 话题串里。
• Permissions。 客户邮件和财务变更会暂停等你审批。新建的定时自动化也会保持暂停，直到有人手动开启。

唯一产品没法替你搭的是 containment，因为它取决于你交出去的凭证。记住那个 93%，用完成任务所需的最低权限去连接他：

• 一个只读数据库账号
• 一个受限的 Stripe key
• 共享的客服收件箱，而不是你的个人邮箱
• 限定特定仓库范围的 GitHub token

他碰不到的东西，他就搞不坏。

图 6. Viktor 的 harness

5. Evals engineering

定义

你怎么知道新员工进步了？拿上个月考过他的同一套题再考一次，然后对比。

没有同一套题，你做的每一次改动都是在猜。Evals 就是你给 Agent 的那套题：一组你已经知道正确答案的任务，每次改动后都跑一遍。

运作原理

有两种检查方式：

• End to end（端到端）。 最终答案对不对？它只能告诉你分数变了，不能告诉你为什么。
• Behavioral（行为级）。 某个具体动作发生了吗？回答前有没有先调 search？需求模糊时有没有追问澄清？说“做完了”之前有没有验证？

行为级检查跑在 trace 上，也就是 Agent 所有操作的日志，而不只是最终答案。Google 的原则是这套测试必须在五秒内跑完，这样才能每次改动都跑。

如果用模型来打分，那就是 judge，而 judge 本身也需要被检查。Airbnb 发现，同样的输入重复跑，他们模型生成的参考答案大约有 75% 前后不一致。他们的 eval 测的其实是自己的噪声。

怎么搭建

1. 从真实翻车现场出发。 翻实际运行记录，找出错在哪，把每一条变成一个测试用例。Airbnb 的黄金集跑 50 到 100 个例子，而且必须包含失败案例。
2. 每个用例写一条行为检查。 一个用例，只验证一件事。
3. 检查你的 judge。 先手工标一批样本，看看你和模型的一致率有多高，再决定信不信它。
4. 抽样生产流量。 Airbnb 每天抽 5% 的线上流量。随着真实使用场景偏移，你的 eval 集会慢慢失效。

单个用例可以小到这种程度：

1input: "退款订单 #1042，客户说收到时坏了"
2expect:
3  - 回复前先查询订单
4  - 退款前先申请审批
5check:
6  - trace 中 send_reply 前有 get_order
7  - trace 中 refund 前有 approval_request

别只盯着整体通过率。整体通过率上涨的同时，某个具体行为可能已经悄悄崩了。要看单项检查。

图 7. 好的 eval 用例从哪来

捷径

没有产品能替你交付这一层，因为只有你知道对你的业务来说，什么才是正确答案。但方法可以直接照搬：

• 两周后，挑 20 个你知道正确答案的话题串。把你不得不纠正他的那些全算进去。
• 每个用例写一条大白话检查。每个数字他都标来源了吗？需求模糊时他追问了吗？任何信息出公司前他暂停了吗？
• 每次改动后重跑这套用例：加了新 skill、改了需求、换了档位。从 Smart 切到 Balanced 能省大约一半额度，所以在彻底切换前先测一下。
• 每周手工抽检五个随机话题串。

整合起来

五层，五个问题。Context 是它能看到什么。Loop 是谁来做决定。Jev 负责低成本的判断。Harness 是它能碰到什么、谁来检查它。Evals 是你怎么知道它行不行。

用 Viktor 的话，其中三层基本是自带的：context、loop 和 harness。Jev、evals 以及你交出去的凭证，依然是你自己的工程活。

如果你今天就要动手，每一层性价比最高的起步动作：

• Context： 把稳定的指令挪进 system prompt，并且别再改它们。
• Loop： 放手让它跑之前，先设好轮次上限和金额上限。
• Jev： 给 Agent 最常做的判断标 200 条样本。
• Harness： 用一个删不掉任何东西的账号跑你的 Agent。
• Evals： 把最近五次翻车写成测试用例。

换成 Viktor，同一天大概是这样：

• Context： 写好公司说明，录制你的第一个 skill。
• Loop： 每个任务都写清“完成标准”，并主动选择合适的档位。
• Jev： 在任何数据流变成他的任务之前，先过滤一遍。
• Harness： 用只读、限定范围的凭证连接他。
• Evals： 存下 20 个真实话题串作为你的第一套测试集。

一天的工作量，五层全覆盖。

我的看法：模型已经不是最难的部分了，围绕它的这五层才是。把它们搭好，你就能在不加人的情况下扩充产能。大多数团队应该直接拿前三层的现成方案，把自己的时间花在决定质量的后两层上：低成本判断和 evals。

感谢 Viktor 赞助本文。

前往 @viktor_com 免费试用。100 美元额度，无需绑卡。完整链接见我的首条回复。

注册时使用优惠码 YARCHI100。

付费合作