“先把任务规格物化成 artifact，再由 orchestrator 启动 rollout；中途做 checkpoint，最后让 verifier 过 gate。”
把这句话换成人话，大概是：
“先把要求写成一个能检查的文件，再让程序安排模型执行；保存中间进度，最后跑测试确认完成。”
信息量几乎没变，气氛却从结对编程变成了召唤仪式。
这两年做 Agent，我越来越频繁地撞见这种语言：物化、编排、轨迹、回放、压缩、固化、接管、护栏、脚手架、Harness、Verifier、Grounding、Handoff。有些词确实命名了新对象，有些是数据库、分布式系统、强化学习和认知科学里的旧词搬了新家，还有一些只是在给普通动作穿西装。
问题不只是“术语太多”。更麻烦的是，同一个词常被不同框架用来指不同东西。团队以为已经达成共识，真正落到状态、接口和验收条件时，才发现每个人脑中运行的是不同系统。
如果只带走一句话，可以记住这句：
Agent 工程术语的核心用途，是给概率模型外面的控制面命名；术语一旦不能指出状态、动作、边界或证据，就从工程压缩退化成了气氛组。
先建立坐标系：所有术语都在给五件事命名
这篇不是按字母排序的词典。词典能解释单词，却解释不了它们为什么成群出现。
更有用的办法，是先把 Agent 看成一个改变外部世界的闭环。它接收目标，把有限信息装进上下文，选择动作，通过工具改变环境，保存必要状态，再用外部证据判断是否完成。ReAct 把“推理—行动—观察”的交错过程带进了主流语言 Agent；CoALA 则更系统地把语言 Agent 放回记忆、动作空间和决策过程组成的认知架构里。
在这个闭环里，只需要盯住五类对象：
- 目标表示：到底要什么，什么不能做，怎样算完成。
- 上下文装配：这一轮让模型看见什么，哪些信息暂时不放进去。
- 行动控制：谁决定下一步，调用什么工具，如何分工和停止。
- 状态延续：跨步骤、跨进程、跨会话保留什么，怎样恢复。
- 完成证据：怎样证明世界真的按要求变化，而不是模型说“完成了”。
flowchart LR
G[目标表示<br/>spec / constraint] --> C[上下文装配<br/>retrieve / compact]
C --> D[行动控制<br/>plan / route / tool]
D --> W[外部世界<br/>文件、数据库、网页、API]
W --> S[状态延续<br/>artifact / checkpoint]
S --> C
W --> V[完成证据<br/>trace / verifier / eval]
V -->|未通过| D
V -->|通过| X[任务完成]这五类对象也是五个工程杠杆：目标越显式，歧义通常越小；上下文越多，召回可能上升，噪声和成本也会上升；行动权越大，能力和爆炸半径一起扩大；状态保存越充分，恢复越稳，过期与一致性问题也越多；验证越硬，可信度越高，但覆盖成本也越高。
后面的新鲜名词，几乎都能塞回这张图。
先拿“物化”开刀：它到底把什么变成了什么
“物化”对应英文 materialize。它不是 Agent 时代才发明的词，也不是一个定义稳定的 Agent 标准术语。
数据库里的“物化视图”是最干净的原型。普通视图保存查询定义，查询时再计算；物化视图把查询结果以类似表的形式保存下来，读取更快，但要面对刷新和数据陈旧的问题。PostgreSQL 的官方文档就是这样定义它的：保存派生结果，用新鲜度换读取成本。
迁移到 Agent 语境后，“物化”常见于三种说法：
- 把意图物化成 artifact：把“修一下登录问题”变成任务规格、补丁、测试或 PR。
- 把派生状态物化下来：把对话里临时算出的计划、摘要或业务对象保存成文件、记录或快照，后续不必重新推导。
- 把候选动作物化成世界变化：不再停留在语言计划，而是真的修改文件、调用 API 或生成可执行对象。
三种用法的共同内核是：把隐式、惰性、临时或需要重新计算的东西，变成显式、可引用、可复用或可检查的对象。 但它们的输入输出完全不同。听到“物化”时不问宾语，基本等于没听。
它还经常和下面几个词混在一起：
| 词 | 真正回答的问题 | 与“物化”的区别 |
|---|---|---|
序列化 serialization | 怎样把对象编码成可存储或传输的字节/文本 | 强调编码格式，不保证对象有工程价值 |
持久化 persistence | 对象能否活过当前进程或会话 | 强调生命周期，不要求它来自一次派生计算 |
检查点 checkpoint | 失败后从哪里恢复执行 | 是带恢复语义的状态快照，不是普通保存 |
实例化 instantiation | 怎样从类、模板或规格得到一个具体实例 | 强调“类型到实例”，不一定存储或执行 |
水合 hydration | 怎样把存储中的瘦数据恢复成可运行对象或当前上下文 | 方向通常与保存相反，来自 Web/ORM 等旧语境 |
物化 materialization | 哪个隐式或派生结果值得提前变成显式对象 | 强调“由潜在到现成”，常伴随成本与新鲜度权衡 |
所以，“把任务物化并持久化到 checkpoint”不是一句信息密度很高的话。它可能只是把三个相邻但不同的动作黏在了一起。更准确的表达应该直接说：把任务规格写成 Markdown；每完成一步，把执行位置和工具结果保存为可恢复快照。
术语地图一：目标与完成条件
| 术语 | 在 Agent 工程里通常指什么 | 身世与判断 |
|---|---|---|
意图 intent | 用户自然语言背后想达成的结果 | NLP 老词；不能替代可验收目标 |
目标 goal / objective | 系统要优化或到达的状态 | 控制与优化老词；要说明是业务目标还是训练目标 |
任务规格 task specification | 输入、输出、约束、资源和完成条件的显式描述 | 软件工程老概念的新载体 |
约束 constraint | 过程中始终不能被违反的条件 | 规划、优化、合规老词 |
策略 policy | 在给定状态下如何选择动作；工程里也常指业务规则 | RL 和治理共享一个词，最容易串台 |
成功标准 success criteria | 外部世界满足哪些条件才算完成 | 项目管理老词，但对 Agent 特别重要 |
验证器 verifier | 用测试、规则、求解器或环境状态判断结果是否正确 | 老概念；在可验证奖励和 Agent 闭环里重新升温 |
评分规程 rubric | 无法硬判对错时，用哪些维度和等级评价 | 教育评估老词；LLM Judge 常依赖它 |
真值 ground truth | 被当作正确参照的标签或世界状态 | 统计学习老词；很多真实任务其实没有完整真值 |
奖励 reward | 训练或搜索时给行为的优化信号 | RL 核心概念；不是业务价值本身 |
| Gate / 质量门 | 不满足条件就不允许进入下一阶段的自动检查 | CI/CD 老概念；比“请模型自觉”可靠 |
这里最需要拆开的，是 verifier、rubric 和 reward。验证器回答“通过没有”，rubric 回答“按哪些维度打分”，reward 回答“训练或搜索应该偏向什么”。三者可以互相生成，却不是同一个东西。把 LLM Judge 的主观分数称为“验证器已经证明正确”，就是把软评价冒充硬证据。
术语地图二：上下文、检索与记忆
| 术语 | 在 Agent 工程里通常指什么 | 身世与判断 |
|---|---|---|
上下文窗口 context window | 一次模型调用能直接处理的 token 范围 | 模型约束，不等于系统的全部记忆 |
上下文工程 context engineering | 为当前决策选择、组织、更新输入信息 | 新组合；内含检索、压缩、权限和时效管理 |
上下文装配 context assembly | 把指令、历史、检索结果、工具定义等拼成一次调用输入 | 系统工程动作；比“塞 Prompt”更准确 |
| Grounding | 用可追溯的外部证据或环境反馈约束生成 | NLP 老概念；中文常译“落地/接地”，不如直接说“证据约束” |
检索增强生成 RAG | 生成前或生成中检索非参数知识 | RAG 论文的原义比“接个向量库”更完整 |
工作记忆 working memory | 当前任务正在使用的短期状态 | 认知科学借词；通常就是受控的当前工作集 |
情景记忆 episodic memory | 以具体经历、轨迹或事件保存的历史 | 认知科学借词；Reflexion把反思文本放进 episodic buffer |
语义记忆 semantic memory | 从多次经历中抽出的稳定事实或概念 | 认知科学借词；与原始事件日志不是一回事 |
记忆流 memory stream | 按时间积累、可检索的经历记录 | Generative Agents中的具体设计，后来常被泛化 |
记忆巩固 memory consolidation | 把多条事件压缩成更稳定的摘要、规则或知识 | 认知科学隐喻；必须说明何时写、怎样纠错 |
上下文压缩 compaction | 在保留任务根和关键证据的前提下缩短上下文 | 数据/存储老词；摘要只是实现之一 |
水合 hydration | 从存储、检索结果或任务包重新组装运行时上下文 | Web/ORM 借词；不是行业统一叫法 |
来源链 provenance | 一条信息从哪里来、何时获取、经过哪些变换 | 数据治理老词；比“模型记得”更可审计 |
MemGPT 是跨领域借词的典型：它明确借用操作系统的分层内存与虚拟内存思想，用快慢层之间的数据移动制造“超出上下文窗口”的效果。这个类比很有生产力，但也容易把人带偏——模型没有一块像人脑那样自主、统一、可靠的“记忆”；通常是应用程序在替它写、检索、压缩和重新注入文本。
因此，“Agent 记住了用户偏好”最好翻译成四个工程问题：存在哪里、谁写入、何时检索、错了怎样删除。回答不了，memory 只是拟人化占位符。
术语地图三：行动、分工与运行外壳
| 术语 | 在 Agent 工程里通常指什么 | 身世与判断 |
|---|---|---|
工作流 workflow | 由程序预先定义主要步骤和分支的执行图 | 自动化老词；是否调用模型不影响它是工作流 |
| Agentic loop | 模型根据观察动态选择下一动作的闭环 | 新组合；“agentic”本身信息量很低 |
规划 planning | 从当前状态构造到目标状态的动作序列或策略 | 经典 AI 老问题，不是大模型发明的 |
任务分解 decomposition | 把一个目标拆成依赖关系更清楚的子问题 | 项目管理、规划与算法老概念 |
工具调用 tool use | 模型选择外部能力、生成参数并消费结果 | Toolformer研究了何时、如何自监督地学会调用 API |
| Function calling | 用受约束结构表达一次函数/工具请求 | 产品接口能力，不等于工具已安全执行 |
路由 routing | 在模型、工具、Agent 或流程分支之间选择目的地 | 网络与系统老词；只负责“送到哪” |
编排 orchestration | 协调顺序、依赖、并发、资源、重试和状态 | 分布式系统老词；负责“整场怎样跑” |
交接 handoff | 把当前处理责任和必要上下文转给另一个 Agent | 组织协作借词；SDK 常把它实现成一种工具调用 |
委派 delegation | 父任务把子任务交给别的执行者，通常仍保留总责任 | 管理学老词；不一定发生控制权转移 |
轨迹 trajectory | 一次任务中状态、动作、观察与结果的有序序列 | RL 老词；描述发生了什么 |
| Rollout | 按某个策略实际采样出的一次候选执行 | RL 老词；强调“跑出一个样本” |
| Trace | 为调试、审计和观测记录的调用与事件数据 | 可观测性老词；是记录，不等于决策轨迹本身 |
| Harness | 包住模型的运行外壳：循环、工具、状态、权限、恢复与验证 | 测试/系统工程借词；边界因团队而异 |
| Scaffold | 用 Prompt、工具定义和控制逻辑搭出的 Agent 实验结构 | 研究社区常用；与 Harness 高度重叠，无统一边界 |
| ACI | 为 Agent 设计的计算机操作接口与反馈格式 | SWE-agent提出 Agent-Computer Interface，类比 HCI |
几个常见误会值得单独拆开。
轨迹、rollout、trace 不是三个时髦同义词。 一次 rollout 会产生一条行为 trajectory；系统可以把其中部分或全部记录成 trace。前两个来自强化学习的行为视角，后一个来自可观测性视角。你可以保留 trace 却无法精确重放 trajectory，也可以拿到最终 trajectory 却缺少模型延迟、token、重试等 trace 数据。
路由不等于编排，交接也不等于委派。 路由只做选择；编排还要管理前后依赖与失败。交接意味着活跃处理者发生变化；委派则可以让父 Agent 等待子结果后继续负责整体验收。OpenAI Agents SDK 的 handoff 文档就把交接表示成给模型看见的工具，这说明它不是神秘的“多智能体协作能力”，而是一个有明确数据流的控制动作。
Harness 也不是模型能力。 同一个模型，换掉文件浏览、编辑命令、错误反馈、上下文截断和验证循环，表现会显著变化。SWE-agent 把这个观察命名为 ACI：Agent 是一种新的软件终端用户，需要专门设计动作和反馈接口。所谓“Agent 变强了”，经常是外壳让它更不容易走丢。
术语地图四：状态、可靠性与安全边界
| 术语 | 在 Agent 工程里通常指什么 | 身世与判断 |
|---|---|---|
状态 state | 决定下一步行为且必须跨步骤保留的数据 | 计算机科学基础概念；不要把整段聊天都叫状态 |
快照 snapshot | 某一时刻状态的只读截面 | 存储老词；未必足以恢复执行 |
检查点 checkpoint | 带恢复位置和必要状态的执行保存点 | HPC、数据库、训练系统老词 |
| Artifact | 任务产生、可引用和交付的对象，如补丁、报告、模型或测试结果 | 构建系统老词；中文可直接说“产物” |
物化 materialization | 把派生或隐式结果变成可直接读取、执行或检查的对象 | 数据库等领域借词；Agent 中定义不稳定 |
持久化 persistence | 让状态活过进程、机器或会话边界 | 存储老词；不自动提供一致性与恢复语义 |
| Durable execution | 在中断、等待或失败后从持久状态继续执行 | 工作流系统老能力在 Agent 长任务中的再包装 |
幂等 idempotency | 同一动作执行多次，业务效果仍等价于执行一次 | 分布式系统老词；付款、发信、建单的救命线 |
重试 retry / backoff | 失败后再次尝试，并逐步拉长等待或切换策略 | 可靠性老词；模型“再想一次”只是其中一种重试 |
可恢复性 recoverability | 失败后能否回到已知状态并继续或补偿 | 系统工程老目标；不等于把异常吞掉 |
| Guardrail | 在输入、输出或工具动作边界执行检查、拦截或降级 | 安全工程隐喻；必须落实到可执行机制 |
| Tripwire | 命中特定条件后立即中断流程的触发器 | 安全隐喻；是 guardrail 的一种行为 |
| Sandbox | 隔离文件、网络、进程、凭据和资源的执行环境 | 操作系统与安全老概念 |
| Capability / permission | 明确某个执行者能对哪些资源做哪些动作 | 安全模型老概念；比 Prompt 里的“不要”更硬 |
| Human-in-the-loop | 在信息补全、审批、纠错或高风险提交点引入人 | 控制系统老模式；不是统一的一颗“人工按钮” |
这组术语大多不新，重要性却真的上升了。原因是过去模型只生成文本，失败最多产出一段坏答案；现在它会改仓库、发邮件、更新订单、操作浏览器。概率输出一旦接上有副作用的工具，幂等、权限、恢复和审计就从“平台团队以后再补”变成产品语义的一部分。
一个真实的 checkpoint 至少要回答：恢复到哪一步、哪些动作已经提交、哪些结果仍可信、恢复后怎样避免重复副作用。LangGraph 的持久化文档把 thread 内的 graph state snapshot 与跨 thread 的长期 store 明确分开，正好说明“保存了”不是一个充分设计。
同样，guardrail 也不是 System Prompt 里加一句“请勿泄露隐私”。OpenAI Agents SDK 的文档把它落实为输入、输出和工具调用前后的检查，并区分并行检查与阻塞检查。能在动作发生前拦截副作用，才配叫护栏；只能事后表示遗憾的，是事故复盘。
术语地图五：观测、评测与训练反馈
| 术语 | 在 Agent 工程里通常指什么 | 身世与判断 |
|---|---|---|
可观测性 observability | 从日志、指标、trace 和事件反推系统内部状态 | 分布式系统老概念；不是“多打点日志” |
| Eval | 对模型或 Agent 在一组任务上的系统性测量 | evaluation 的简称；必须说明数据、指标与重复次数 |
| Benchmark | 可复用、可比较的任务集与测量协议 | 科研基础设施；不等于线上目标 |
| Grader / Judge | 给输出打分的程序、规则、人或模型 | 评价执行者；模型 Judge 仍可能偏置和漂移 |
| Verifier | 检查候选结果是否满足可判定条件 | 强于一般 grader，但只在它覆盖的条件内可靠 |
pass@k | 生成 k 个候选时，至少一个成功的能力 | 适合看探索上限，容易掩盖单次不稳定 |
pass^k | 同类任务连续运行 k 次都成功的一致性 | τ-bench 提出的可靠性指标，更贴近生产且通常更残酷 |
| RLVR | 用可程序验证的结果做强化学习奖励 | “可验证”降低打分歧义，不消除奖励漏洞 |
| Reward hacking | 系统找到拿高分但违背真实意图的捷径 | RL 老问题；验证器越窄越容易被钻空子 |
| Acceptance test | 从使用者或业务角度检查交付是否可接受 | 软件工程老词；常比语言流畅度更接近终态 |
这里最危险的词是“验证”。测试通过，只能证明测试覆盖的性质成立；LLM Judge 给高分，只能证明它在那份 rubric 和当时模型下给了高分。把 trace 存下来也不等于可观测：OpenAI Agents SDK 的追踪文档会记录生成、工具调用、handoff 与 guardrail 等事件，但工程师仍要把这些事件和业务终态关联起来，才知道任务究竟成没成。
哪些词是真需求，哪些词只是旧酒换瓶
把上面六十多个词压缩一下，可以分成三类。
第一类：旧概念遇到了新的爆炸半径
幂等、检查点、沙箱、权限、可观测性、编排都很老。它们在 Agent 时代重新变热，不是因为模型发明了它们，而是因为原本确定性较高的执行系统里，塞进了一个概率决策内核。
过去程序员写死“下一步调用退款接口”；现在模型根据自然语言和局部上下文决定“下一步是什么”。决策边界移动之后，状态、新鲜度、权限、回滚和验证都必须重新设计。旧词仍然准确，只是过去不做分布式系统的人也被迫面对它们了。
第二类：跨领域隐喻制造了新的组合
Agent 研究非常喜欢借词，而且论文自己往往明确承认这种借用：
- CoALA 从认知科学与符号 AI 借来记忆、动作空间和决策架构。
- MemGPT 从操作系统借来虚拟内存、分层存储和中断。
- Reflexion 从强化学习借来“强化”，却用语言反馈和 episodic memory 代替权重更新。
- Voyager 把可执行代码积累成 skill library，并用环境反馈、自验证迭代技能。
- SWE-agent 从 HCI 类比出 ACI，把模型当成需要专用界面的计算机用户。
这类词不必嘲笑。好的隐喻能把成熟领域的失败经验一起搬过来：一旦你说“检查点”，就应该想到恢复一致性；一旦你说“物化”，就应该想到刷新与陈旧；一旦你说“权限”，就应该想到默认拒绝和最小授权。
真正的问题是只搬名字、不搬约束。把一段聊天记录叫“长期记忆”，却没有写入策略、版本、删除和冲突处理；把几个 Prompt 串起来叫“认知架构”，却没有状态模型和动作边界——这不是跨学科，是跨领域借壳。
第三类：无法落到接口上的气氛词
agentic、self-evolving、cognitive layer、semantic operating system、autonomous fabric 之类的词不一定错，但单独出现时几乎没有工程信息。
判断它是不是包装词，只做一个删除实验：
把这个词从设计文档删掉，团队是否会失去一个明确的数据结构、接口、控制权、失败模式或验收方法？
如果什么都没丢，它大概率只是语气增强器。
究其本质：为什么这个领域会长出这么多新名词
原因一：系统边界真的移动了，工程师需要给新控制面命名
LLM 不是完整 Agent，只是一个根据上下文生成下一个输出的概率组件。工具、状态、循环、权限和验证把它变成能持续行动的系统。每多接上一层，工程师就多出一组以前藏在程序代码里的选择：
- 哪些信息进上下文？
- 谁决定调用工具？
- 中断后从哪里继续？
- 什么时候允许写入真实世界？
- 谁来证明完成？
这些选择必须出现在架构图、接口、日志和事故报告里，所以它们需要名字。术语首先是组织复杂度的压缩算法。 checkpoint 比“那份能让我们从第三步恢复且避免重复发邮件的数据”更适合团队协作。
原因二：Agent 是交叉学科的汇合口，借词比重新发明快
一个生产 Agent 同时碰到 NLP、强化学习、数据库、工作流、操作系统、分布式系统、安全、HCI 和评测。每个领域都带来一套成熟词汇，而相同英文在不同领域又有不同含义。
于是会出现很奇怪的会议：研究员说的 policy 是动作分布，业务同事说的是退款政策；做训练的人说 rollout，平台同事把它理解成发布；前端同学说 hydration，Agent 工程师却指恢复上下文。词没错，坐标系没说。
原因三：论文、产品和框架都需要给边界取名
论文需要指出“我的方法和已有方法差在哪里”，产品需要把能力包装成可发现的功能，框架需要稳定的类名、事件名和 API。一个概念一旦变成 Handoff 类型、Guardrail 回调或 trace 面板，它就从比喻变成了可传播的产品语言。
这会形成一条放大链：
flowchart LR
P[论文为差异命名] --> D[文档与 API 固化名称]
D --> M[模型从语料与上下文学会搭配]
M --> U[工程师让模型写方案和文档]
U --> C[更多仓库、博客、会议沿用]
C --> D一个词能广泛流行，不等于它已经形成稳定定义；很多时候只是它很适合当标题、类型名和架构图方框。
原因四：大模型会放大“像专业人士说话”的统计风格
这里要非常克制。我们能确认现象，却还不能给出一个已经被证明的单一原因。
《Delving into LLM-assisted writing》分析了超过 1500 万篇 PubMed 摘要，观察到 ChatGPT 出现后，一批风格词的频率突然上升。这说明模型不只在传递内容，也会把某种词汇指纹批量写回人类文本。
后续的《Why Does ChatGPT “Delve” So Much?》识别出 21 个同时满足“近期激增”和“ChatGPT 相对人类过度使用”的焦点词。但它对原因的结论并不爽快：没有找到架构、算法或训练语料导致词汇过度代表的直接证据；基础模型与对话模型的比较与“微调/RLHF 可能有作用”一致，专门做的人类偏好实验却没有得到统一支持。词汇偏好是真现象，成因仍未定论。
放到工程术语上，我更愿意把下面几条写成有证据约束的推断，而不是“模型内心喜欢装专业”：
- 预训练让模型学习技术语料里哪些词经常一起出现；它输出的是高概率延续，不会主动核验这个名词在你团队里有没有严格定义。
- 指令微调和人类反馈会改变表达风格。InstructGPT证明人类反馈能把输出推向人类更偏好的“有帮助”形式，但这不等于 RLHF 已被证明是工程黑话的唯一来源。
- 当用户使用
rollout、harness或“物化”时，模型会顺着已建立的专业语域继续补全相邻词。每个词局部合理，整段却可能术语密度过高。 - 模型缺少真实项目中的共同经验，只能用语言来表示它“理解了架构”。名词化很适合制造边界清晰的表面；如果没有文件、调用和测试去 grounding，这些边界可能只存在于句子里。
Murray Shanahan 在《Talking About Large Language Models》里提醒，模型越擅长模仿人类语言，我们越容易用“知道、相信、思考”之类带哲学负担的词描述它。对工程黑话也该做同样的降温：不是模型“想显得专业”，而是系统在当前上下文和训练后偏好下，生成了很像专业文本的 token 序列。
原因五：中文直译会给旧概念再镀一层陌生感
materialize 译成“物化”，grounding 译成“接地”，hydrate 译成“水合”，harness 有人译成“挽具”、有人直接保留英文。英文读者可能一眼看出它来自哪个旧领域，中文读者拿到的却是一层脱离历史语境的新壳。
所以技术讨论中保留英文并不可耻。更好的写法通常是第一次出现时给出“英文 + 本文中的操作性定义”，后面再用中文简称。最糟的是只保留一个漂亮译名，让读者自己猜数据流。
一套术语祛魅协议
下次再看到一个新名词，不必立刻背，也不必条件反射地嘲笑。连续问六个问题：
- 它的输入和输出是什么？ “物化”了什么，变成什么？
- 它改变了哪类状态？ 模型上下文、应用状态，还是外部世界？
- 它在闭环的哪个位置？ 目标、上下文、动作、状态还是证据？
- 控制权在谁手里？ 模型、确定性程序、工具、平台还是人？
- 失败模式是什么？ 陈旧、重复执行、越权、丢上下文，还是验收误判？
- 不用这个词能否说清楚？ 如果能，先用普通话说一遍，再决定缩写是否值得保留。
例如：
“Harness 在每轮 rollout 后把状态物化到 checkpoint，并由 verifier 决定是否继续。”
经过祛魅，可以写成：
“运行程序每完成一步，就把当前步骤、已执行工具及其结果保存到数据库；测试程序检查仓库状态，未通过就把错误反馈给模型继续修改。”
第二句更长，但它暴露了可实现、可争论、可测试的对象。等团队真的共享这些定义后，再压缩回 harness、checkpoint 和 verifier，术语才开始产生价值。
最后的判断：不是拒绝术语，而是要求术语支付房租
Agent 工程会继续造词，因为系统仍在快速分化，研究、产品和平台还没有稳定边界。试图彻底消灭术语既不现实，也没有必要。
真正该反对的是不用定义就预支共识。
checkpoint 如果带来可恢复执行，值得保留；materialization 如果明确了派生状态、刷新策略和读取成本，值得保留；handoff 如果落实了责任转移与上下文过滤，也值得保留。反过来，一个词若不能落到状态、接口、权限、失败模式或验证证据上，就应该被翻译回普通动词。
说到底，大模型没有凭空创造一门新工程学。它站在几十年软件工程、AI 和认知科学词汇的交叉口，把社区刚刚重新组合的概念，以极高速度复述、扩散，有时也过度包装。
所以当模型下一次告诉你“需要将隐式意图物化为可观测 artifact”时，不妨回它一句：
具体写哪个文件、改哪条状态、谁来验收？
如果它答得出来，那个术语可能有用。如果答不出来，你遇到的不是新技术，只是一个生成得很顺的名词。
论文与资料索引
Agent 架构与工程对象
- ReAct: Synergizing Reasoning and Acting in Language Models
- Cognitive Architectures for Language Agents (CoALA)
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Toolformer: Language Models Can Teach Themselves to Use Tools
- Generative Agents: Interactive Simulacra of Human Behavior
- Reflexion: Language Agents with Verbal Reinforcement Learning
- Voyager: An Open-Ended Embodied Agent with Large Language Models
- MemGPT: Towards LLMs as Operating Systems
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
模型语言与词汇偏好
- Training Language Models to Follow Instructions with Human Feedback
- Talking About Large Language Models
- Delving into LLM-assisted Writing in Biomedical Publications through Excess Vocabulary
- Why Does ChatGPT “Delve” So Much?
工程定义