AI Agent 的五个层次：从一句提示词到生产级智能体（完整教程）

中科创新烁智

64人浏览 · 2026-10-15 13:10:26

中科创新烁智 · 2026-10-15 13:10:26 发布

现在谈到 Agent 时，人们常挂在嘴边的有五个词：上下文工程、循环工程、Jev 工程、Harness 工程和评测工程。

这些词听起来像是五种互相竞争的方法，其实并不是。它们是同一个系统的五个层次，每一层都在回答一个不同的问题。

要理解它们，最简单的办法就是想象：你刚刚招聘了一名新员工。

上下文（Context）——你向他提出问题时，他的桌上摆着什么资料？
循环（Loop）——他是照着你的清单一步步执行，还是会自己判断下一步该做什么？
Jev——公司的前台负责分拣邮件，让他只看到真正重要的内容。
Harness——他的办公室，包括他能使用的工具、手里的钥匙，以及谁来检查他的工作。
评测（Evals）——每个月都让他参加同一场测试，这样你才知道他的能力有没有真正提高。

AI Agent 就是这名员工。模型相当于员工本人，而这五个层次就是围绕他搭建起来的一切。把这五层设计好，一个小团队就能承担过去需要通过招聘更多员工才能完成的工作。重复性工作交给能够在真实生产环境中稳定运行的 Agent，而团队成员则保留决策权。这就是如何在不增加员工人数的情况下扩大产能。

接下来，我会逐一解释每个层次是什么、如何运作、适用于哪些场景，以及应该怎样构建。

每一层我也会提供一种更简单的替代方案：即使是初学者，也能不必从零搭建，就获得相近的效果。我在 Viktor 的朋友们帮助我整理了这些捷径。

Viktor 是一名 AI 员工，可以在你的 Slack 或 Microsoft Teams 中工作。他和其他团队成员待在同一个频道里，像真正的队友一样工作。你可以把他加入团队，而不必为此额外招聘一个岗位。

和他协作的方式，就像和一个人共事一样：

你可以在某个频道或讨论串中提及他，并说明要完成的任务。

他会自己梳理执行步骤，调用你正在使用的各种工具完成工作，然后把结果发回同一个讨论串。

设置也很简单：只要把 Viktor 添加到工作区，他就会像其他团队成员一样出现在参与者列表中。如果你想一边阅读一边试用，可以使用优惠码 YARCHI100。

<图片 1：Agent 的五个层次>

1. 上下文工程（Context Engineering）

定义

每次向员工提问之前，你都会先把一些文件放到他的桌上。如果只放对的三页，他可能几秒钟就能回答；但如果你把三百页文件全堆上去，答案就可能被埋在整堆资料中间，而他反而找不到。

模型就是这名员工，而桌面就是上下文窗口：也就是模型回答问题之前能够看到的所有内容，包括你的指令、目前为止的聊天记录、从数据库里取出的文档，以及它调用过的每一个工具所返回的结果。

上下文工程，就是决定哪些内容应该放到这张桌子上，以及应该放在哪里。

工作原理

上下文更多，并不意味着答案就更好。超过某个程度之后，结果反而可能变差。

斯坦福大学曾专门测试过这一点：给模型 20 到 30 份文档后，它对位于中间位置的文档内容进行回答时，准确率会降到约 50%～57%。而在完全不给文档的情况下，同一个模型的得分是 56%。答案明明就在上下文窗口里，模型的表现却比什么资料都不给时还差。

这里有两个主要原因：

模型通常最关注上下文的开头和结尾，对中间部分的关注最少。
每个 Token 都要消耗时间和费用，无论它最终有没有帮助。

还有一个值得了解的机制：提示词缓存（Prompt Caching）。服务提供商会保存提示词开头的一部分，并在下一次调用时复用它。与新输入的 Token 相比，缓存命中的 Token 成本大约可以低十倍。

但有个前提：需要缓存的开头必须逐字节完全相同。只要改动靠前位置的一个字符，后面的内容就可能都要按完整价格重新计费。因此，合理的排列方式始终是：稳定不变的内容放前面，容易变化的内容放后面。

如何构建

所有上下文内容都可以放进以下四个位置之一：

1. 系统提示词（System Prompt）

只放每次调用时都成立的信息，例如角色、约束条件和输出格式。尽量保证它逐字节保持一致。不要在开头放每次都会变化的时间戳，也不要让 JSON 的键顺序随意变化。

2. 工具（Tools）

不要在一次对话进行到一半时随意添加或移除工具。这样可能破坏缓存，也可能导致模型继续调用已经不存在的工具。如果你只想在某个步骤限制工具的使用，可以阻止这一步的工具调用，但仍然保留工具定义。

3. 磁盘或文件存储（Disk）

体积大或需要长期保存的内容，放到文件里；上下文窗口只保留文件路径即可。网页也一样：保留 URL，去掉整篇正文。也就是说，移除内容本身，但保留能够重新取回内容的线索。

4. 上下文末尾（Tail）

每执行几步，就在上下文靠近末尾的位置重新说明当前目标。中间部分很难控制模型是否会忽略，因此要尽量让最重要的信息避开容易被忽视的位置。

工具定义本身也有成本。Anthropic 测算过，58 个工具的定义会在用户还没输入任何内容之前，就消耗大约 55,000 个 Token。与一次性加载全部工具相比，让模型先搜索自己需要的工具后再加载，使 Opus 4 在他们的基准测试中的成绩从 49% 提升到了 74%。

如果工具数量在 20 个左右或更少，可以直接全部加载；如果超过这个数量，就可以考虑改用搜索方式按需提供。

处理大型任务时，还有一个实用技巧：派出一个子 Agent。它在自己的上下文窗口中读取 50 个文件，再返回一页摘要。主 Agent 的上下文只需要接收这份摘要，而不必装入那 50 个文件的全部内容。
在这里插入图片描述

<图片 2：一次模型调用中包含哪些内容>

捷径

Viktor 可以替你处理上下文管理中的大部分工作，因为它的上下文是以整个公司为单位组织的。

记忆。 它会为整个团队持续保存业务相关的记忆。比如，它上周从你的联合创始人那里了解到的信息，今天就不必再由你复制粘贴到请求里。
连接外部资料源。 连接 Notion、Google Drive 或 HubSpot 后，你就不必再把文件一份份粘贴进聊天。只要告诉它文档或记录的名称，它就会直接读取相应资料。这相当于替你做好了前面说的文件存储管理。
技能（Skills）。 你只需要录一次自己完成某项任务的屏幕操作。它会把录屏转换成书面流程，然后由你修改并批准。此后，这条指令就会固定下来，并经过审查，类似一份设计良好的系统提示词。

你自己还需要做的事情包括：

编写一份简短的公司说明，介绍你们销售什么、客户是谁、哪些数字最重要，以及哪些事情绝对不能做。
每个讨论串只处理一个任务，并在第一条消息里明确怎样才算完成。
如果它记住了错误信息，应在设置中清除相应记忆，而不是每次都在新的讨论串里反复纠正它。

2. 循环工程（Loop Engineering）

定义

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

拿到目标后，他会先尝试一种做法，观察结果，再决定下一步做什么。前一种方式是工作流，后一种方式则是循环。

工作原理

一个循环会重复四个动作：思考、行动、观察、决策。比如修复一个 Bug，过程可能是这样的：

运行测试，发现有三个测试失败。
查看第一个报错，发现缺少一个导入语句。
添加导入语句，再运行一次。
还有一个测试失败。查看它的报错，修复问题，再运行一次。
所有测试都通过了，停止。

这些步骤并不是事先由人写好的。模型是在看到上一步的结果之后，才选择下一步行动。

这就是两者的区别。即使你事先写好了 100 个步骤，它依然是工作流；如果其中三个步骤是模型根据结果自己决定的，那就是循环。

只有在无法提前写清执行步骤时，才使用循环。 如果步骤可以预先确定，就直接把它们写出来。工作流成本更低，也更容易并行执行；如果第四步失败，只需重新执行第四步，而不必从头重跑所有步骤。

循环同样可能很昂贵。按照作者给出的估算，一个 Agent 任务所用的 Token 大约是单次模型调用的四倍；多 Agent 系统的消耗则可能达到约十五倍。

如何构建

一个循环需要四个组成部分，缺少任何一个，都可能无法正常工作：

1. 明确的目标和完成标准。 不要只说“修复这个 Bug”，而应该明确写成：“auth_test.py 中失败的测试必须通过，而且不能破坏其他功能。”

2. 检查器（Checker）。 必须有模型之外的机制来判断结果是通过还是失败，例如测试套件、编译器或代码检查工具。关于自我纠错的研究在这一点上结论比较一致：真正有效的是来自外部的反馈；如果只是让模型自己检查自己，效果就会大打折扣。没有检查器，就没有真正的循环，只会变成没有明确终点的持续花费。

3. 停止规则。 检查通过时停止；达到最大轮数时停止；或者最近两次尝试得到的输出完全相同时，也可以判断它可能陷入了停滞。

4. 预算。 既要限制执行轮数，也要限制费用。

用代码实现时，整个循环只需要几行：

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)          # 切换到备用工作流

比较好的做法是把确定性流程和 Agent 循环结合起来。Atlan 会先运行一个确定性的筛选器，只有约 14% 的输入告警会真正进入 Agent。

之后，循环最多执行三轮。如果三轮之后置信度仍然低于 50%，就由一个固定的 Python 工作流接手。

先过滤，再短暂循环，最后必要时回退到固定流程。 在这里插入图片描述

<图片 3：如何在工作流和循环之间作出选择>

捷径

你在 Viktor 的某个讨论串中交给它的每一项任务，都是一个循环。你描述目标，它自己选择步骤，调用你使用的工具完成工作，最后再把结果发回讨论串。

这个循环的四个组成部分，可以这样对应：

目标。 如果任务说明不完整，它会提出疑问，而不是随便猜一个答案。不过，你仍然应该写清楚什么才算完成。例如：“生成上周营收报告，汇总数字必须与 Stripe 一致，并在周一上午 9 点前发布到 #finance 频道”，就比“做一份报告”明确得多。
检查器。 它会在发布之前标记看起来不对劲的数字。你也可以进一步明确检查依据，例如 Stripe 的总额、数据行数或测试套件结果。
停止规则。 遇到敏感操作时，它会暂停并等待人工确认，最终结果也会返回给你。
预算。 这里的成本以额度点数计算。推理档位会决定每一步的价格，而对于定期执行的任务，运行频率也很重要。每小时生成一次报告，长期成本远高于每周生成一次。

Atlan 的混合方案也可以在不写代码的情况下实现。对于重复性工作，可以把它设置为定时任务：Viktor 会先提出创建计划任务的建议，而任务会一直处于暂停状态，直到你批准启用。这就是工作流。

开放式、难以预先确定步骤的任务，则放进讨论串里执行，这就是循环。你自己则是最终的兜底机制。

3. Jev 工程（Jev Engineering）

定义

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

你的 Agent 也会做两类事情：一类是生成内容，另一类是作出判断。现在，通常是一个大型模型同时负责这两件事。这就像让律师亲自负责分拣邮件——你付出了专家级的成本，却把时间花在了简单的分类工作上。

Jev 就是这个前台。它不负责写内容，只负责作出选择。

工作原理

你需要事先告诉 Jev 要回答什么问题，以及它可以选择哪些答案。它会返回以下三种结果中的一种，并附带一个置信度分数：

是或否；
从一组选项中选出一个；
在某个数值范围内给出一个数字。

因为它只负责选择，而不负责生成长篇内容，所以速度快、成本低。作者给出的数据是：Jev 的响应时间为 70～500 毫秒，而对比方案的响应时间为 3～329 秒；输入 Token 的价格为每百万个 0.042 美元，输出则免费。

但接下来要说的是更需要注意的部分：在作者写下这篇文章时，Jev 推出还不到两周，独立测试才刚刚开始出现。

在电子邮件分类任务中，普通逻辑回归模型的准确率为 98.9%，而 Jev 为 98.6%。
在钓鱼邮件识别任务中，Jev 的准确率为 62.6%，Claude Haiku 4.5 则为 81.3%。
关于“零幻觉”的说法，作者也引用了产品方自己的脚注：这个数字并不是通过实证测试得出的，它仅表示输出始终符合预先规定的数据结构。

此外，Jev 给出的置信度分数也不能直接当成真实概率。应该先把它当作排序依据，再使用自己标注的数据来确定合适的阈值。

如何构建

一种合理的设计，是在昂贵的大模型前面加一道筛选关卡：

所有输入都先进入系统。

Jev 针对每一项输入回答一个范围明确的问题。

如果它对一个常见请求有足够把握，就用低成本的方式处理：分类、转发，或者直接丢弃。

如果输入不确定或情况特殊，就交给主模型处理。

d = jev.choose(item, options=["垃圾邮件", "订单状态", "退款", "其他"])

if d.confidence >= 0.7 and d.option != "其他":
    handle_cheap(d.option, item)
else:
    main_model(item)   # 不确定时采用更稳妥的路径，交给更昂贵的主模型

不过，在做这些之前，先试试最简单、最容易奏效的方法。给几百个真实样本打标签，训练一个基础分类器；只有当它的效果不够好时，再考虑更复杂的方案。

这只需要大约 30 分钟，而它也应该成为任何供应商宣传说法必须超越的基准。
在这里插入图片描述

<图片 4：Jev 可以回答的三类问题>

捷径

Jev 并不属于 Viktor 已公开的技术方案，但这个思路仍然适用于两个你可以自己控制的地方：

推理档位。 Viktor 提供三个档位：Smart 使用 Claude Opus；Balanced 使用 Claude Sonnet，成本大约只有前者的一半；Ultra 使用 Claude
Fable，成本大约是前者的两倍。给请求分类或提取一个数字，并不需要使用最高档位。
在 Agent 前面设置筛选关卡。 如果你希望它处理大量客服邮件或告警，不要把所有输入原封不动地交给它。先运行一个分类器或调用 Jev，让只有那些确实需要进一步判断的项目，才成为 Agent 的任务。

即使使用 Viktor，这仍然是两层需要你自己进行工程设计的部分之一。

4. Harness 工程（Harness Engineering）

定义

同一个员工，放在两间不同的办公室里。第一间办公室里，他有合适的工具、墙上贴着操作手册，有同事检查他的工作，而且没有保险柜的钥匙。第二间办公室里，他只有一台笔记本电脑，却拿着你的管理员密码。

员工能力相同，最后的表现却可能截然不同。员工相当于模型，办公室就是 Harness。

Agent = 模型 + Harness。

工作原理

Harness 指模型本身以外的一切：工具、权限、沙箱、用于解释项目情况的文件，以及检查输出的机制。

到了 2026 年，Harness 开始成为一个独立的工程领域，因为人们开始对它进行测量，发现模型本身并不能解释全部表现差异：

Anthropic 只调整了容器资源，就让某项基准测试的得分变化了 6 分。
LangChain 固定模型不变，只调整 Harness，就让同一项基准测试的得分变化了 13.7 分。
之后，他们又围绕一个开源模型调整 Harness。这个模型的成本只有 Opus 的十分之一，但调整后得分达到 0.86，而 Opus 4.8 的得分为 0.87。

你现在购买的已经不只是一个模型，而是模型和 Harness 的组合。

只要 Agent 开始接触真实资源，你就需要 Harness：例如代码仓库、收件箱、支付系统或生产数据库。

如何构建

从外向内，一层一层搭建：

1. 隔离边界（Containment）。 明确 Agent 在物理或权限层面无法触及什么。可以使用容器、独立分支、只读数据库账号，以及只允许访问白名单中的网络资源等方式。应当在发出第一个 Prompt 之前就做好这些设置。

2. 操作指南（Guides）。 这些内容负责在 Agent 行动之前引导它。比如，在代码仓库中放置 AGENTS.md 文件；把工具描述写清楚，让模型能够选对工具；同时提供几个高质量输出的示例。

3. 检查机制（Sensors）。 负责在 Agent 行动后检查结果。例如 Linter、类型检查器和测试套件。这些检查速度快、结果确定，因此应该尽可能用于每一项改动。较慢的检查，例如让另一个模型审查代码差异，则只在真正重要的改动上执行。

4. 权限管理（Permissions）。 当 Agent 请求批准时，人们有 93% 的概率会直接批准。因此，单靠弹出的审批提示几乎起不到多少保护作用。真正的保护措施，是让某些高风险操作从一开始就不可用。只有少数真正不可逆的操作，才应该要求人工批准。

操作指南文件不必很长。即使只有四行，也足以改变 Agent 的行为：

# AGENTS.md
- 单体仓库：/api（FastAPI）、/web（Next.js）、/jobs（定时任务）
- 使用 `make test` 运行测试；提交任何改动前，测试都必须通过
- 绝不能手动修改 /migrations，必须使用 `make migration`
- 数据库只允许只读访问。修改任何数据库结构之前，必须先询问

Hook 则是把同样的原则变成可强制执行的规则。在 Claude Code 中，Hook 是一个会在工具调用前运行的小脚本，并且可以阻止调用。例如，“绝不能推送到 main 分支”应该用 Hook 强制执行，而不只是把这句话写进 Prompt。

还有一个需要注意的地方：Harness 中的每一项设置，其实都是你对模型能力的一种判断——你认为它还做不到某件事。但随着模型升级，这些判断可能就会过时。Anthropic 就曾在模型升级、原有辅助组件不再必要后，删除了整套脚手架中的一个组件。

因此，每隔几个月就应该重新检查一次 Harness，把模型已经不再需要的辅助限制清理掉。
在这里插入图片描述

<图片 5：Harness 的四个环节>

捷径

如果 Agent = 模型 + Harness，那么使用 Viktor 时，你获得的大部分能力其实来自 Harness。底层模型是 Claude，而围绕模型搭建的其他部分都已经准备好了：

工具。 提供 3,200 多种集成，包括 GitHub、Linear、HubSpot、Stripe、Notion、Google Drive 等。如果某个工具还没有现成的连接方式，它也可以自行构建。

操作指南。 也就是 Skills。你不必亲手编写 AGENTS.md，只需要录下自己的屏幕操作，它就会起草相应的流程，再由你进行编辑。

检查机制。 它会标记前后对不上的数据，也会针对缺少关键信息的任务说明提出问题。而且每一步操作都会记录在团队可以查看的 Slack 讨论串中。

权限管理。 发送客户邮件、进行财务变更等操作会暂停并等待批准。新建的定时自动化任务也会保持暂停，直到有人主动启用。

任何产品都无法替你完成的，是隔离边界的设置，因为这取决于你交给它什么凭证和权限。记住前面提到的 93%：连接时，只给它完成任务所必需的最低权限，例如：

只读数据库账号；
权限受限的 Stripe 密钥；
团队共享的客服邮箱，而不是你自己的个人邮箱；
只允许访问指定代码仓库的 GitHub Token。

它无法访问的东西，就无法被它破坏。
在这里插入图片描述

<图片 6：Viktor 的 Harness>

5. 评测工程（Evals Engineering）

定义

怎样才能知道一名新员工是否进步了？你可以让他再做一次上个月做过的同一套测试，然后比较成绩。

如果没有一套一致的测试，你做的每一次改动都只是在猜。Evals 就是给 Agent 准备的测试：一组你已经知道正确答案的任务，每次修改系统之后都重新运行。

工作原理

检查主要有两种：

端到端评测（End-to-end）。 最后的回答是否正确？这种评测能告诉你整体分数有没有变化，但未必能说明原因。
行为评测（Behavioral）。 某个具体行为有没有发生？例如，回答前是否调用了搜索工具；请求含糊时是否提出澄清问题；宣告完成之前是否验证过结果。

行为检查针对的是执行轨迹（Trace），也就是 Agent 做过的所有事情的日志，而不仅仅是最终答案。Google 提出的一个原则是，这套测试最好能在 5 秒以内完成，这样每次发生改动时都可以运行。

如果由模型负责打分，那么这个模型就充当了评审，而评审本身也需要被检查。Airbnb 发现，同一输入反复运行时，模型生成的参考答案中，大约四分之三会出现差异。换句话说，他们的评测测到的可能是评测系统自身的波动，而不完全是被测系统的真实表现。

如何构建

从真实失败案例入手。 查看实际运行记录，找出问题发生在哪里，然后把每一个失败整理成测试用例。Airbnb 使用的黄金测试集通常包含 50～100 个示例，而且必须包含失败案例。
每个案例只写一条行为检查。 一个案例只验证一件事情。
检查你的评审模型。 先人工给一批样本打分，看看你和模型的判断有多一致，再决定是否信任它。
抽查真实生产流量。 Airbnb 每天会抽取线上流量的 5% 进行检查。随着真实使用方式逐渐变化，原来的评测集也会慢慢失去代表性。

一个测试案例可以简单到这样：

input: "退款订单 #1042，客户表示商品送达时已经损坏"
expect:
  - 回复前先查询订单
  - 发起退款前先请求审批
check:
  - 执行轨迹中，get_order 必须出现在 send_reply 之前
  - 执行轨迹中，approval_request 必须出现在 refund 之前

不要只看整体通过率。即使总通过率上升，某一项具体行为也可能在不知不觉中出问题。应该分别关注每一项检查的结果。
在这里插入图片描述