概念辨析补遗：各种 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 | 装配层与生命周期 | 回合插口接线、会话写入时序、扩展事件 | 装配错误、持久化时序、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说，“处理什么、产出什么、怎么验证，定义了你管多大范围；容易和谁混，标注了边界上的坑。范围是静态描述，验收是动态动作。做工程的人读表，先扫验证方式那列，那决定你交付后能不能睡安稳觉。”
“我能不能拿这张表去面试官面前对号入座？”
“能，但有一种用法要小心。”老Z说，“表是帮你描述自己做了什么的，不是帮你跟面试官争论岗位定义的。说‘我主要负责 Agent engineering，涉及 Loop 和 Tools 的边界’，这是在描述职责，有用；说‘按你的定义这不叫 Agent engineering’，这是在争定义，没用。定义不统一是常态，你能做的是把自己的职责翻译成对方听得懂的术语，而不是纠正对方的术语。”
这些词会不会都覆盖同一批工作？
小A盯着表格看了半天：“Prompt 这行管指令，Context 这行管资料，RAG 这行管检索，横看竖看都是围着模型转。这九行，该不会是同一批活拆成了九份吧？”
老Z：“会有重叠，而且重叠是常态。一个 RAG 产品同时需要数据工程（摄取索引）、模型工程（Provider 接入）、应用工程（会话循环）和安全工程（权限审计）。区别通常在于团队把什么当作主要风险和交付物，而不是存在一条权威边界。”
“‘容易混淆’那列，是不是专门处理这种重叠的？”
“对，那列先把混淆摆出来，再谈分工。”老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 的事。判断标准不是谁改的这段文字，是错的根因在指令还是在资料。重叠本身不出事，重叠区没人认领才出事，出了故障互相推。”
“再给一个具体的问法，”老Z说，“把这段文字删掉，错会消失还是还在？删掉的是指令，错就出在 prompt；删掉的是资料，错就出在 context。用删除实验归因，比开会辩论‘谁负责这段’快得多，结论还可复现。”
小A接得很快：“RAG 答错的话，我就删掉检索的语料段落试试？”
“对，删一样、看结果。”老Z说，“错还在，问题在生成，不在检索；Agent 行为不对，删掉某个工具，行为变了，这个工具就是参与方。这套思路对所有重叠区都适用，它不依赖任何术语定义，只依赖可复现的对比。”
一个例子：同一个仓库，九种视角
老Z给小A出了道题：拿 pi-mono 当标本，把九种视角挨个往上套。以下出处均按本书源码篇基线（上游 pi 标签 v1.0.0，提交 a13d35a7）标注，便于你在对应快照中核对：
- 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/coding-agent/src/core/compaction/compaction.ts的completeSummarization。- RAG engineering 视角：看 skills 怎么发现和加载（虽然 pi 的 skills 更像指令包，不是经典 RAG）。出处：
packages/coding-agent/src/core/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 视角：看评测 harness 怎么建临时环境、收集 artifact，文档对照实验怎么配对。出处：
packages/evals/src/harness.ts的createPiCodingAgentHarness、src/report.ts。- Loop engineering 视角：看双层循环（steer/followUp 队列 + tool 执行）、checkpoint、abort。出处：
packages/agent/src/agent-loop.ts的runAgentLoop、getFollowUpMessages队列与finishTurn插口。- Graph engineering 视角：看 session fork 的分支树、compaction 的检查点。出处：
packages/coding-agent/src/core/session-manager.ts的createBranchedSession、packages/coding-agent/src/core/compaction/compaction.ts。- Harness engineering 视角：看宿主怎样把会话写入、压缩、扩展和请求投影接到循环的插口上。
v1.0.0把实验性的AgentHarness从 pi-agent-core 删掉了，这层装配落在产品层。出处：packages/coding-agent/src/core/agent-session.ts的AgentSession构造函数与_install*方法。
“九个视角里，有几个特别容易让人觉得看的是同一个文件。”老Z说，“比如 Loop engineering 和 Agent engineering，都落在 agent-loop.ts 上：前者看‘循环怎么转’（状态机、停止条件、中止），后者看‘Agent 整体怎么运转’（会话、工具、边界）。文件重叠不等于关注点重叠，两个人对着同一份代码，一个关心它的转移条件，一个关心它的外接契约，做的是两件事，不是重复劳动。”
“反过来说，不同的文件也可能属于同一个视角。”老Z说，“Eval engineering 的验证方式分散在 harness、artifact 收集、配对报告好几处，是同一个视角在不同文件里的落地。判断视角，看的是关注对象和验证方式，不是文件路径。这也是本附录用‘视角’而不用‘模块’来切的原因：模块是代码的组织方式，视角是关注的组织方式，两者不是一一对应。”
“还有一个实际用途，排障时拿视角当过滤器。”老Z说，“出了问题先问它属于哪个视角：是 prompt 写错（视角一），上下文没选对（视角二），还是循环没判好停止（视角七）？锁定视角，排查范围就从整个仓库缩到一个方向。这跟故障手册里‘先定位到层’是一个道理，只不过这里定位到的是视角。”
“所以这些术语不是互相排斥的工种，是同一系统的不同切面。”老Z补了一句，“pi-mono 的分层只说明这一个仓库的组织方式，证明不了这些术语在所有组织里含义相同。”
小A：“九个视角里，有没有哪个是前提，别的都建在它上面？我猜是 Loop engineering，循环转不起来，其他都白搭。”
“猜得有道理，但答案不是它。”老Z说，“接近前提的是 Harness engineering。它管装配层和生命周期：回合插口接线、会话写入时序、扩展事件。装配错了，其他八个视角全都跑不起来；装配对了，它们才有对象可看。这不表示它更高级，只表示它是地基视角，地基不显眼，塌了谁都站不住。把视角排成‘装配 → 循环 → 工具 → 上下文 → 模型 → 评测’，你得到的不只是九种切面，还是一条按依赖排序的阅读路线。”
小A：“九种凑齐了，是不是就约等于‘全栈 Agent 工程师’？”
“凑齐的是技能集合，不是一个岗位。”老Z说，“一个人可以九种都会，但在一个团队里，他通常只对其中一两种负主要责任。‘全栈’说的是广度，不是职责范围。九个都懂的人，排障时最有价值；九个都负责的人，验收时最痛苦。”
用户的原始观点：它们是不是“换了个词的软件工程”？
小A想起自己最初的疑问：“不瞒你说，刚看到这张职位图时，我心里嘀咕的是‘这不就是咱们天天在干的活吗’。现在看完这几张表，这个念头还立得住吗？”
老Z笑了：“半对半错。”
- 对的部分：它们用的方法（版本管理、测试、code review、CI、监控、事故复盘）确实是软件工程的通用方法。Prompt engineering 要做回归测试，RAG engineering 要做评测集，Agent engineering 要做失败路径测试，这些和传统软件工程没有本质区别。
- 错的部分：但它们处理的对象不同。软件工程方法仍然适用；Agent 系统把确定代码、概率模型和真实副作用组合在一起，需要把模型行为波动纳入验证和监控。模型会幻觉、会漂移、会随版本变化，这是传统软件工程较少面对的非确定性，所以测试方法、监控指标、事故归因都要调整。
“先看对的那一半。”老Z说，“你学过的软件工程方法，没有一个是浪费的，版本管理、测试、review、CI 都是所有工程的通用底座。新工种里，底座全是旧的；要改的都是上层。所以碰到一个新的 X Engineering，第一步永远是问‘哪些方法可以直接沿用’，先把不必要的新问题排除掉，再谈哪里真的不一样。”
小A：“‘错的那一半’里，最先要调整的是什么？”
“回归测试的地位。”老Z说，“传统软件里，回归测试是‘改了代码，确认没把旧功能改坏’，它是保险，不是主体。在概率性系统里它成了主体：模型每次更新、prompt 每次改动，都得跑一遍覆盖样本集，确认没退步。这道弯转不过来，后面一切工程手段都会失去基准。”
老Z又指出一条更隐蔽的差异：“‘修好了’的定义变了。传统软件里，‘修好了’是这个 bug 不再出现；模型世界里，‘修好了’常常是这一类样本的错误率下降了，而错误率是统计量，不是真假值。你面对的是一个只会说‘大部分时候对’的系统，就得接受‘足够好’。这不是妥协，是对象本身的性质决定的。”小A把“统计意义上的修复”写进了笔记。
老Z把‘概率性’这个词展开：“传统软件的 bug，复现路径是确定的，同样输入同样输出，修了就修了。模型不是。同一个 prompt，这次答对，下次答错；你改 prompt 改对了一类样本，可能同时把另一类样本改坏。所以‘我本地跑通了’下不了结论，得看‘跑了一个覆盖样本集，前后对比没退步’。”
“那‘概率性’对排障的影响呢？传统 bug 有堆栈，模型错误可没有。”
“对，这是排障观的分水岭。”老Z说，“传统软件的报错能一步步跟到根因，堆栈、断点、数据流都能定位；模型的‘报错’常常只是‘这次输出不对’，没有堆栈，只有一次样本。你能做的，是把‘一次不对’变成‘一个样本集不对’：多跑几次，看是系统性偏误还是偶发波动。偶发波动再跑一次可能就对，系统性偏误得改 prompt 或改资料。没有样本集，连这是 bug 还是运气都分不清。”
“还有别的被‘概率性’改变的传统环节吗？”
“监控指标和事故复盘。”老Z说，“传统服务看错误率、延迟；Agent 服务还要加行为类指标，比如工具调用成功率、每任务轮次、停止原因分布。复盘也变了：传统事故问‘哪行代码写错了’，Agent 事故的答案常常是‘那类样本没覆盖到’。前者定位代码，后者定位样本和 prompt，把代码视角硬套到概率性系统上，复盘会越复越糊涂。”
“所以更准确的说法是，”老Z总结，“它们是软件工程面对概率性系统时的延伸，不是换名。方法还是那些方法，对象变了，验收标准、测试策略和质量定义就都得重新校准。”
小A：“从传统软件工程转过来的人，最先要学的新技能是什么？”
“最先要学的不是某个框架，是接受不确定性的心态。”老Z说，“传统工程里‘确定’是默认值：同样的代码产生同样的结果，出了 bug 才是反常。模型工程里反了过来，‘不确定’是默认值，同样的 prompt 每次都略有不同，稳定命中才是反常。转过来的第一课，是把‘为什么又不一样’换成‘这次不一样在哪个维度上’，前者是抱怨，后者是分析。心态转了，样本集、评测、回归这些工具才学得进手。”
遇到新名词的四问
小A：“那以后再冒出新的 X Engineering，我怎么判断它是不是真新东西？”
老Z给了四问：
- 它处理什么输入和状态？ 是 prompt？是上下文？是检索语料？是循环状态？
- 它产出什么工件？ 是 prompt 版本？是索引？是工具契约？是评测集？
- 它如何验证？ 是覆盖样本？是召回率？是任务成功率？是可复现运行？
- 失败由谁承担？ 是 prompt 作者？是数据团队？是 Agent 工程师？是运维？
“这四问的答案，比标签更能指导实现。”老Z说，“四个答案都和某个已有术语重合，那它大概率是营销造词；有至少一个答案明显不同，就值得单独对待。辨析的价值也在这里：它逼你回答，这个新名词到底让我多了一道什么验收、多了一份什么责任。答得出来，它是真东西；答不出来，它就是换了张皮的旧岗位。”
“四问里最容易答不上来的是第四问。”老Z说，“前三问是描述性的，产品文档就能回答；第四问是责任性的，得组织里有明确的 owner 才行。团队里没人说得出‘做砸了算谁的’，这个术语的边界就是虚的：东西在流动，责任没人认领。第四问答得越清楚，分工越实。”
小A：“四个答案都和旧术语重合，还有个程度问题吗？重合 100% 才算造词，还是重合一部分就要警惕？”
“看是哪个答案重合。”老Z说，“前三问重合，说明它技术上是旧的，只是把旧东西换了个名字，要警惕；第四问重合，说明组织上没新增责任，没有新的人要为新结果负责，也要警惕。反过来，只要第四问答出了‘一个新增的 owner 和一个新增的验收项’，哪怕前三问全是旧的，它也值得当新分工对待。”
“同一个新名词，在面试和在工作里，四问的用法一样吗？”
“不一样。”老Z说，“面试里，四问是表达工具，用它们描述你做过什么，让面试官从你的描述里看到真能力；工作里，四问是审计工具，检查一个新名词是不是给老活换了新皮，是不是把责任切碎了没人负责。介绍自己用前者，审查名词用后者，别用反了。”
小A若有所思：“那我要是新造一个名词，比如‘Boundary Engineering’，这四问对我自己也是个检验？”
“对，这也是四问最狠的用法。”老Z说，“造词之前先自问：我处理什么输入？产出什么？怎么验证？失败谁承担？四个都答得上，你造的是一个真分工；四个都答不上，你造的就是一个 PPT 词汇。这套问题对外帮你识破别人的营销词，对内也拦得住你自己的造词冲动。”
回到全书目标：新名词还会不断冒出来。手里有这四问，哪些是真实关注点、哪些只是招聘文案，你自己就能分辨。
小A把那张职位图重新贴在了笔记本上。这一次，他先不问“我到底属于哪个头衔”，拿四问把九个头衔挨个过了一遍。头衔还是那九个，问法变了。下次再有人递给他一张新的职位图，他知道该从哪里问起。