概念辨析补遗：各种 Engineering 到底在说什么

小a在公司内部看到一张职位图：Prompt Engineer、RAG Engineer、Agent Engineer、AI Engineer、Context Engineer、Eval Engineer、Loop Engineer、Graph Engineer、Harness Engineer……他数了数，发现自己“好像全都得会”，又“好像哪个都不是”。他拿着图去找老z。

“这些头衔是真有不同工种，还是 HR 在造词？”小a问。

“两者都有。”老z说，“本附录服务概念篇与实现篇，当术语影响分工、交付物或验证方式时查阅。名称没有统一行业定义——同一家公司里，‘AI Engineer’可能指模型微调，也可能指应用集成。本表比较的是常见关注对象，不把它们降格为‘只是软件工程改名’，也不把它们升格为‘全新的学科’。”

“读这张表之前，先定一个原则，”老z说，“比较术语，要比‘关注对象、交付物、验证方式’，不要比‘谁更高级’。 九个头衔里没有一个‘统领所有其他’的——它们管的东西不同，验证的侧重点也不同。谁更高级是组织政治问题，不是概念问题。本附录只回答后者：每个 X Engineering 在管什么、怎么验收、容易和谁混。”

小a：“那我是不是可以按‘我做的是哪一块’，来决定我该看哪一行？”

“对，而且这是最自然的读法。”老z说，“你现在做的是‘写 prompt 调模型’，那你看 Prompt engineering 和 Context engineering 两行；你做‘跑评测’，看 Eval engineering；你做‘写工具和循环’，看 Agent engineering 和 Loop engineering。先定位自己在哪一行，再看相邻行怎么混——这张表对号入座比通读更有用。”

九张对账单：每个 X Engineering 到底在管什么

老z让小a先把图上的头职拆成“它处理什么、产出什么、怎么验证、容易和谁混”四列。

术语	主要关注对象	常见可交付物	验证方式	容易混淆
Prompt engineering	指令、示例、输出约束	prompt 版本、测试集	覆盖样本、回归比较	不能替代权限校验
Context engineering	进入模型的资料和状态	选择／压缩／记忆策略	引用正确性、token 与遗漏分析	不等于 KV cache 优化
RAG engineering	摄取、索引、检索与引用	语料、索引、评测集	召回、忠实性、权限测试	不等于“消除幻觉”
Agent engineering	loop、工具、会话与边界	工具契约、状态图、审计	任务成功、失败路径、安全测试	不等于多 Agent
AI／LLM engineering	模型服务接入与产品运行	Provider、可观测性、成本策略	可靠性、成本、质量评测	范围常随组织而变
Eval engineering	质量测量及其数据	cases、rubric、artifacts	可复现运行、人工／自动判定	judge 分数不是绝对真相
Loop engineering	循环控制流与状态机	stop reason、checkpoint、轮次预算	失败路径、预算耗尽、中止可诊断	不等于任意 while 循环
Graph engineering	节点、边与路由	工作流图、条件分支、重放契约	路径覆盖、死锁检测、幂等性	不等于 DAG 库
Harness engineering	装配层与生命周期	phase 状态机、pending writes、hook 接线	装配错误、持久化时序、shutdown	不等于 DI 容器

这张表只为有可核对出处的术语列来源——没有明确出处的（如 AI／LLM engineering，范围随组织而变，无统一出处）不列入，避免把社区说法硬当成定义。需要先说明：这些术语大多没有 ISO 式的统一标准，这里列的是社区和权威机构里流传最广的出处，且没有统一出处不等于没有含义，只说明它还在演化中。 出现时间按可核对出处（论文发表、指南发布、提出者原帖）粗略估计，新兴术语之间的先后并不精确，排序只为展示出现的先后脉络。

术语	出现时间（约）	社区／权威出处（可核对）
RAG engineering	2020	Lewis et al.《Retrieval-augmented generation for knowledge-intensive NLP tasks》（NeurIPS 2020，原始论文）；Gao et al. 2023 综述（arXiv:2312.10997）
Prompt engineering	约 2022	PromptingGuide.ai《Prompt Engineering Guide》（社区权威指南）；Anthropic 与 OpenAI 各自的官方提示工程指南
Eval engineering	约 2023	OpenAI evals 开源框架与社区文档；LLM evaluation 社区综述（如 DeepEval、LangSmith 的评估文档）
Agent engineering	2024	Anthropic《Building Effective Agents》（Erik Schluntz、Barry Zhang，2024-12）区分 workflows 与 agents；OpenAI 与 LangChain 的 agent 工程文档
Context engineering	2025	概念由 Tobi Lütke 与 Andrej Karpathy 在 X（原推特）上提出；IBM Think《Context engineering》专题；Thoughtworks Technology Radar 条目；arXiv《Context Engineering 2.0》（2025）
Harness engineering	约 2025-2026	Mitchell Hashimoto（HashiCorp 联合创始人）提出；OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》；CMU 等《Agent Harness Engineering: A Survey》
Loop engineering	约 2025-2026	社区新兴概念，如《Agent Loop 是什么？为什么？怎么做？》等社区文章；David Khourshid 关于“循环即图”的说法
Graph engineering	约 2025-2026	LangChain／LangGraph 的状态图文档；David Khourshid“循环就是有向有环图”的说法；社区文章（如《Loop Engineering 与 Graph Engineering》）

“这表比上一张多了个‘出处’维度。”小a说，“意思是不是说，每个术语都能追溯到某个作者或机构？”

“对，但要分两类看。”老z说，“有原始出处的——比如 RAG 能追溯到 Lewis 2020 的 NeurIPS 论文，Agent 与 Workflow 的区分能追溯到 Anthropic 那篇《Building Effective Agents》——这类你可以放心引用；只有社区用法的——比如 Loop、Graph——这类你引用时要说明‘这是社区用法，不是标准定义’，而不是假装它有一个权威定义。至于没有统一出处的，比如 AI／LLM engineering，直接不把它当定义引用——你可以在团队内部约定一个口径，但不要对外说‘这个词的官方定义是……’。写进文章或简历时，宁可说‘我按某篇文章的定义使用这个词’，也不要说‘这个词的官方定义是……’。”

“那本书里的工作定义，和这些社区出处是什么关系？”

“本书把社区出处当作参考基准，但给它加了一层工程约束。”老z说，“社区定义回答‘这个词通常指什么’；本书的术语落点回答‘在这个项目的上下文中，我们用这个词指什么、它不等于什么’。两者不冲突：先知道社区的通常用法，再声明本书的约定——这样既不跟社区脱节，也不让定义含糊。遇到分歧时，以可核对出处为准，不凭印象争论。”

小a把表横看了一遍：“这几列里，哪一列最能区分‘真工种’和‘假头衔’？”

“验证方式那一列。”老z说，“关注对象和交付物都可能被营销话术打扮，但‘你怎么验证做得好不好’很难假装——RAG 要测召回和忠实性，Agent 要测任务成功率和失败路径，Eval 要测可复现性。**一个头衔如果说不清‘做好了怎么证明’，它就还没长成工种，只是名字。**反过来，术语是真是假，最硬的判据就是它的验证方式是否具体可执行。”

小a：“那同一行里，四列的关系是什么？”

“前三列是范围，第四列是验收。”老z说，“‘处理什么、产出什么、怎么验证’定义了你管多大范围，而‘容易和谁混’标注了边界上的坑。范围是静态描述，验收是动态动作。做工程的人读表，先扫验证方式那列——那决定你交付后能不能睡安稳觉。”

小a：“我能不能拿这张表去面试官面前对号入座？”

“能，但要小心一种用法。”老z说，“表的目的是帮你描述自己做了什么，不是帮你跟面试官争论岗位定义。说‘我主要负责 Agent engineering，涉及 Loop 和 Tools 的边界’——这是在描述职责，有用；说‘按你的定义这不叫 Agent engineering’——这是在争定义，没用。定义不统一是常态，你能做的是把自己的职责翻译成对方听得懂的术语，而不是纠正对方的术语。”

这些词会不会都覆盖同一批工作？

小a：“这些词会不会都覆盖同一批工作？”

老z：“会有重叠，而且重叠是常态。一个 RAG 产品同时需要数据工程(摄取索引)、模型工程(Provider 接入)、应用工程(会话循环)和安全工程(权限审计)。区别通常在于团队把什么作为主要风险和交付物，而不是存在一条权威边界。”

小a：“那张表里的‘容易混淆’那列，是不是专门处理这种重叠的？”

“对。那列的价值在于先声明混淆，再谈分工。”老z说，“比如表里写着‘Context engineering 不等于 KV cache 优化’——这句话不是在纠正术语，是在划‘概念边界’和‘性能边界’：Context engineering 管的是‘模型看到什么’，KV cache 管的是‘计算怎么复用’。前者决定正确性，后者决定速度。把两件本不该混的事列在一起，你才不会在‘上下文变长’的讨论里，把缓存命中率当成答案。”

老z打了个比方：“就像‘前端’‘后端’‘全栈’——这三个词的重叠区比任何一家公司的 JD 都大。但你不会因此说‘它们是同一个岗位’。各种 X Engineering 也一样：关注点不同，工具不同，验收标准不同，哪怕它们碰的代码有交集。”

小a：“那看一张表能不能一眼找出‘哪两行的重叠最容易出事’？”

“能，盯‘容易混淆’那列最长的几行。”老z说，“写‘不等于’的，都是现实中真的发生过混淆的——表里不写‘等于’，写‘不等于’的地方，就是坑。比如‘RAG engineering 不等于消除幻觉’，说明它俩在现实中常被画等号；画上等号，就会把‘检索召回率’当成‘幻觉率’来验收，两个指标都做不好。‘容易混淆’那列，就是事故高发区的路标。”

小a追问：“那这种重叠什么时候会变成问题？”

“当它模糊责任归属时。”老z说，“比如 prompt 和 context 的边界——prompt 是‘我写了什么指令’，context 是‘我让模型看到了什么’。这两者都进了同一个请求，但谁该为‘模型答错了’负责？如果是 prompt 写歪了，那是 prompt engineering 的事；如果是上下文里塞进了过时的文件，那是 context engineering 的事。判断标准不是‘谁改的这段文字’，而是‘错的根因在指令还是在资料’——前者归 prompt，后者归 context。重叠不可怕，可怕的是重叠区没人认领，出事互相推。”

“再给一个判责任的具体问法，”老z说，“‘如果我把这段文字删掉，错会消失还是还在？’ 删掉的是指令，错了的是 prompt；删掉的是资料，错了的是 context。用‘删除实验’归因，比开会辩论‘谁负责这段’要快得多——根因归因不是岗位问题，是可复现实验的问题。”

“这个删除实验还能推广到更多重叠区。”老z说，“RAG 答错了，删掉检索的语料段落，错还在——那问题在生成，不在检索；Agent 行为不对，删掉某个工具，行为变了——那这个工具就是参与方。‘删一样、看结果’这套思路，是所有重叠区归因的统一工具：它不依赖任何术语定义，只依赖可复现的对比。用一次，你就不会在‘是谁的责任’上吵超过十分钟。”

一个例子：同一个仓库，九种视角

老z让小a用 pi-mono 这个仓库举例，看同一个代码库能被几种视角切入。以下出处均按本书源码篇基线（pi-mono 提交 583f153d，路径为包内相对路径）标注，便于你在对应快照中核对：

• Prompt engineering 视角——看 system prompt 怎么组装（基础规则 + 工具说明 + 项目资料 + 任务），怎么版本化，怎么用探针测试。出处：packages/coding-agent/src/core/agent-session.ts（会话内提示词装配）。
• Context engineering 视角——看 buildContextEntries 怎么选消息、compaction 怎么压缩、trim 怎么裁剪。出处：packages/coding-agent/src/core/session-manager.ts 的 buildContextEntries、packages/agent/src/harness/compaction/compaction.ts 的 completeSimpleWithRetries。
• RAG engineering 视角——看 skills 怎么发现和加载（虽然 pi 的 skills 更像指令包，不是经典 RAG）。出处：packages/agent/src/harness/skills.ts 的 loadSkills。
• Agent engineering 视角——看 runAgentLoop 怎么推动状态、工具怎么执行、stop reason 怎么判定。出处：packages/agent/src/agent-loop.ts 的 runAgentLoop、packages/agent/src/agent.ts 的 Agent。
• AI／LLM engineering 视角——看 ModelsImpl 怎么接入 Provider、认证怎么合并、成本怎么控制。出处：packages/ai/src/models.ts 的 ModelsImpl、packages/ai/src/auth/resolve.ts 的 resolveProviderAuth。
• Eval engineering 视角——看 pi-harness 怎么建临时环境、收集 artifact、对比 faux 与真实模型。出处：packages/evals/src/pi-harness.ts 的 createPiCodingAgentHarness。
• Loop engineering 视角——看双层循环（steer/followUp 队列 + tool 执行）、checkpoint、abort。出处：packages/agent/src/agent-loop.ts 的 runAgentLoop 与 getFollowUpMessages 队列。
• Graph engineering 视角——看 session fork 的分支树、compaction 的检查点。出处：packages/agent/src/harness/session/fork.ts 的 readSessionEntriesForFork、packages/agent/src/harness/compaction/compaction.ts。
• Harness engineering 视角——看 AgentHarness 的 phase 状态机、pending writes、hook 接线。出处：packages/agent/src/harness/agent-harness.ts 的 AgentHarness（phase 字段与 pendingSessionWrites）。

“九个视角里，有几个特别容易让人觉得‘看的是同一个文件’。”老z说，“比如 Loop engineering 和 Agent engineering，都落在 agent-loop.ts 上——前者看的是‘循环怎么转’(状态机、停止条件、中止)，后者看的是‘Agent 整体怎么运转’(会话、工具、边界)。文件重叠不等于关注点重叠：两个人对着同一份代码，一个人关心它的转移条件，一个人关心它的外接契约——这是视角不同，不是重复劳动。”

“反过来说，不同的文件也可能属于同一个视角。”老z说，“Eval engineering 的‘验证方式’分散在 pi-harness、artifact 收集、对比脚本好几处——它们是同一个视角在不同文件里的落地。判断视角，看的是‘关注对象和验证方式’，不是看文件路径。 这也解释了为什么本附录用‘视角’而不是‘模块’来切：模块是代码的组织方式，视角是关注的组织方式，两者不是一一对应。”

“还有一个实际用途，”老z说，“排障时用视角当过滤器。 一个问题，先问它是哪个视角的问题——是 prompt 写错(视角一)，还是上下文没选对(视角二)，还是循环没判好停止(视角七)？**锁定了视角，排查范围就从整个仓库缩到一个方向。**九种视角不只是用来理解术语的，也是用来给故障分类的——这跟故障手册里‘先定位到层’是一个道理，只不过这里定位到的是视角。”

“同一个仓库，九种视角，每种都能讲出不同的故事。”老z说，“这说明这些术语不是互相排斥的工种，而是同一系统的不同切面。pi-mono 的分层说明某个仓库的组织方式，不证明这些术语在所有组织中含义相同。”

小a：“九个视角里，有没有‘哪个视角是前提，别的视角都建立在它上面’？”

“有一个接近前提的：Harness engineering。”老z说，“它管装配层和生命周期——phase 状态机、pending writes、hook 接线。装配错了，其他八个视角全都跑不起来；装配对了，其他八个视角才有对象可看。但这不表示它‘更高级’，只表示它是地基视角——地基不显眼，但塌了谁都站不住。把视角排成‘装配 → 循环 → 工具 → 上下文 → 模型 → 评测’，你得到的不只是九种切面，还是一条按依赖排序的阅读路线。”

小a：“那九种视角合在一起，是不是就约等于‘全栈 Agent 工程师’？”

“合在一起是技能集合，不是一个岗位。”老z说，“一个人可以九种都会，但在一个团队里，他通常只对其中一两种负主要责任。‘全栈’这个词描述的是广度，不是职责范围。技能集合是个人能力，视角是团队分工——别用前者的野心，掩盖后者该有的清晰。九个都懂的人，在排障时最有价值；九个都负责的人，在验收时最痛苦。”

用户的原始观点：它们是不是“换了个词的软件工程”？

小a想起自己最初的疑问：“我一开始觉得，它们只是换了个词的软件工程。这个说法对吗？”

老z笑了：“半对半错。”

• 对的部分——它们用的方法(版本管理、测试、code review、CI、监控、事故复盘)确实是软件工程的通用方法。Prompt engineering 要做回归测试，RAG engineering 要做评测集，Agent engineering 要做失败路径测试——这些和传统软件工程没有本质区别。
• 错的部分——但它们处理的对象不同。软件工程处理确定性的代码，而这些 X Engineering 处理概率性的模型行为。模型会幻觉、会漂移、会随版本变化——这是传统软件工程较少面对的非确定性。所以测试方法、监控指标、事故归因都要调整。

“先看对的那一半，”老z说，“你学过的软件工程方法，没有一个是浪费的。版本管理、测试、review、CI——这些是所有工程的通用底座。**所谓‘新工种’里，底座全是旧的；所谓‘旧方法’里，要改的都是上层。**所以面对一个新 X Engineering，第一步永远是问‘哪些方法可以直接沿用’——先把不必要的新问题排除掉，再谈哪里真的不一样。”

小a：“那‘错的那一半’里，最先要调整的是什么？”

“回归测试的意义。”老z说，“传统软件里，回归测试是‘改了代码，确认没把旧功能改坏’——它是保险，不是主体。在概率性系统里，回归测试变成了主体：模型每次更新、prompt 每次改动，都必须跑一遍覆盖样本集确认没退步。传统软件里测试是‘防线’，这里测试是‘准绳’——这一条观念转不过来，后面一切工程手段都会失去基准。”

“还有一条隐蔽的差异，”老z补了一句，“**‘修好了’的定义变了。**传统软件里‘修好了’是‘这个 bug 不再出现’；模型世界里‘修好了’常常是‘这一类样本的错误率下降了’——而错误率是统计量，不是真假值。**你在跟一个只会说‘大部分时候对’的系统打交道，就得学会接受‘足够好’而不是追求‘绝对对’。**这不是妥协，是对象的物理属性决定的。”小a把“统计意义上的修复”写进了笔记。

老z把‘概率性’这个词展开给小a看：“传统软件的 bug，复现路径是确定的——同样输入同样输出，你修了就修了。 模型不是。同一个 prompt，这次答对，下次答错，你改 prompt 改对了一类样本，可能同时把另一类样本改坏。这意味着回归测试的权重远高于‘修了就算’——你不能靠‘我本地跑通了’下结论，你得靠‘我跑了一个覆盖样本集，前后对比没退步’。这就是为什么 eval 在这些 X Engineering 里地位特殊：它是传统软件工程里‘可选’的东西，在这里是‘必须’的东西。”

小a：“那‘概率性’对排障方式的影响呢？传统 bug 有堆栈，模型错误可没有。”

“对，这是排障观的分水岭。”老z说，“传统软件的报错可以一步步跟到根因——堆栈、断点、数据流，都能定位；模型的‘报错’常常是‘这次输出不对’，没有堆栈，只有一次样本。你唯一能做的，是把‘一次不对’变成‘一个样本集不对’——多跑几次，看是系统性偏误还是偶发波动。偶发波动再跑一次可能就对，系统性偏误需要改 prompt 或改资料。没有样本集，你连‘这是 bug 还是运气’都分不清。”

小a：“还有别的被‘概率性’改变的传统环节吗？”

“监控指标和事故复盘。”老z说，“传统服务用错误率、延迟这些指标；Agent 服务还要加‘行为类’指标——比如‘工具调用成功率’‘每任务轮次’‘停止原因分布’。**事故复盘也一样：传统事故问‘哪行代码写错了’，Agent 事故常常答‘那类样本没覆盖到’。**两套语言都能用，但对象不同——前者定位代码，后者定位样本和 prompt。把‘代码视角’硬套到概率性系统上，复盘会越复越糊涂。”

“所以更准确的说法是，”老z总结，“**它们是软件工程在面对概率性系统时的延伸，不是换名。**方法还是那些方法，但对象变了，所以验收标准、测试策略和质量定义都要重新校准。”

小a：“既然对象变了，那一个人从传统软件工程转过来，最先要学的‘新技能’是什么？”

“不是某个框架，是接受不确定性的心态。”老z说，“传统工程里‘确定’是默认值——同样的代码产生同样的结果，出了 bug 是反常。模型工程里‘不确定’才是默认值——同样的 prompt 每次都略有不同，稳定命中才是反常。转过来的第一课，是把‘为什么又不一样’这个问题，换成‘这次不一样在哪个维度上’——前者是抱怨，后者是分析。心态转了，后面的工具(样本集、评测、回归)才学得进手。”

遇到新名词的四问

小a：“那以后再冒出新的 X Engineering，我怎么判断它是不是真新东西？”

老z给了四问：

1. 它处理什么输入和状态？——是 prompt？是上下文？是检索语料？是循环状态？
2. 它产出什么工件？——是 prompt 版本？是索引？是工具契约？是评测集？
3. 它如何验证？——是覆盖样本？是召回率？是任务成功率？是可复现运行？
4. 失败由谁承担？——是 prompt 作者？是数据团队？是 Agent 工程师？是运维？

“这四问的答案，”老z说，“**比标签更能指导实现。**如果四个答案都和某个已有术语重合，那它大概率是营销造词；如果有至少一个答案明显不同，那它值得单独对待。换句话说——**辨析的用处不在分类本身，而在于它逼你回答‘这个新名词到底让我多了一道什么验收、多了一份什么责任’。**答得出来，它就是真东西；答不出来，它就是换了张皮的旧岗位。”

“四问里最容易答不出来的是第四问。”老z说，“前三问是描述性的——产品文档就能回答；第四问是责任性的——得组织里有明确的 owner 才行。一个术语，如果团队没人说得出‘做砸了算谁的’，那它的边界就是虚的：东西在流动，责任没人认领。第四问答得越清楚，分工越实；答得越含糊，重叠区越容易变成互相推诿的无人区。”

小a：“四个答案都和旧术语重合的时候，是不是还有个程度问题——重合 100% 才算造词，还是重合一部分就要警惕？”

“看是哪个答案重合。”老z说，“前三问重合，说明它技术上是旧的——只是把旧东西换了个名字，警惕；第四问重合，说明它在组织上没新增责任——没有新的人要为新结果负责，警惕；但如果第四问答出了‘一个新增的 owner 和一个新增的验收项’，哪怕前三问全是旧的，它也值得当新分工对待。判断新不新，第四问的分量大于前三问之和。”

小a：“那同一个新名词，在面试和在工作里，四问的用法一样吗？”

“不一样。”老z说，“面试里，四问是表达工具——用它们描述你做过什么，让面试官在你的描述里看到真能力；工作里，四问是审计工具——用它们检查一个新名词是不是给老活换了新皮，是不是把责任切碎了没人负责。同一个四问，一个拿来介绍自己，一个拿来审查名词——别用错了场景。”

小a若有所思：“那我要是新造一个名词，比如‘Boundary Engineering’，这四问对我自己也是个检验？”

“对，而且这正是四问最狠的用法。”老z说，“造词之前先自问：我处理什么输入？产出什么？怎么验证？失败谁承担？**四个问题都答得上，你造的是一个真分工；四个问题答不上，你造的就是一个 PPT 词汇。**工具是公平的——它既帮你识破别人的营销词，也帮你识破自己的造词冲动。”

回到全书目标：遇到新名词时先问这四件事——它处理什么、产出什么、如何验证、失败由谁承担。答案比标签更能指导实现，也能帮你识破哪些是真实关注点，哪些只是招聘文案。

小a把那张职位图重新贴在了笔记本上。这一次，他没有再问“我到底属于哪个头衔”，而是对着每个头衔问起了同一组问题：处理什么？产出什么？怎么验证？做砸了算谁的？——头衔还是那九个，但他看见的不再是九个职位，而是九个各有验收标准的切面。他知道，下次再有人递给他一张新的职位图，他手里已经有了一把能拆任何名词的工具。