Agent执行系统中的身份与版本设计

很多团队第一次做 Agent 执行系统时，都会先问几个很"工程化"的问题：Run 要不要 ID？Step 要不要 ID？Task 要不要版本号？Agent 升级后，旧任务还能不能继续？Prompt 改了以后，Resume 到底该用旧版还是新版？

这些问题表面上是在讨论字段，背后其实只有一个核心：当一次执行被暂停、失败、重试或恢复时，系统能不能准确回答"我现在继续的，到底是不是原来的那次执行"。

只要支持 Resume，这就不再是日志问题，而是执行语义问题。

Run ID 不只是给一次运行起名字，而是建立一次执行的唯一身份。

同一个 Task 可以执行很多次。即使两次输入相同，也不代表它们是同一件事：第一次可能已经调用外部 API，第二次可能还没有；第一次可能写入数据库，第二次可能只完成推理。

没有 Run ID，系统很难判断哪些状态、日志、工具调用结果和检查点属于哪一次执行。一旦出现重试、并发、人工介入或 Resume，问题会迅速放大。

所以，只要 Agent 不是一次性函数调用，而是具备生命周期的执行单元，Run ID 基本应该存在。

Step 要不要 ID，取决于系统是否需要"从步骤级别继续"。

假设一个 Agent 有三个动作：查订单、调用退款接口、发送通知。执行到退款后系统崩了。恢复时，如果只知道"Run 没结束"，却不知道退款是否已经成功，就可能重复退款。

这时 Step ID 的价值就出现了：它把某一步的输入、输出、状态、副作用和重试绑定起来。

Step ID 不一定非要是随机 UUID，也可以是"Run ID + Step 序号"，或者由工作流节点和循环次数组成。关键是它必须稳定，能唯一定位一次具体步骤执行。

如果 Step 只是纯计算、没有副作用，也不支持局部恢复，Step ID 可以弱化。但只要涉及外部系统、幂等、审计或断点续跑，就应该认真设计。

很多人把 Task 当成静态定义，但真实系统里的 Task 会变化：流程节点会改，输入字段会改，工具选择和判断条件也会改。

这时只有 Task ID 不够。

假设"客户退款"昨天有三步，今天改成五步。一个昨天暂停的 Run 今天恢复，如果系统只按 Task ID 读取最新版定义，那么它恢复的已经不是原来的任务。

因此，只要 Task 定义可能变化，就应该有版本概念。它未必叫 Task Version，也可以叫 workflow_version、definition_version。名称不重要，重要的是一次 Run 必须绑定明确的任务定义。

Agent 升级可能只是修日志，也可能更换模型、工具、状态结构甚至决策逻辑。两者都叫"升级"，但对 Resume 的影响完全不同。

更稳妥的做法，是把兼容性写成明确规则，而不是假设"新版本总能接旧任务"。

例如，可以分三类：兼容升级允许旧 Run 直接 Resume；需要迁移的升级先转换旧状态；不兼容升级则继续使用旧 Agent 版本完成旧 Run，或者明确终止并重新创建任务。

这和数据库升级很像。代码发布新版本，不代表历史数据天然符合新结构。Agent 的执行状态也一样。

如果一次 Run 已经开始，Prompt 就属于这次执行上下文的一部分。

假设任务执行到一半，系统 Prompt 从"优先保证准确性"改成"优先追求速度"。如果 Resume 时直接读取最新 Prompt，同一个 Run 前后两段行为就可能遵循不同规则。技术上虽然"恢复"了，语义上却已经换了执行者。

更安全的原则是：新 Run 使用新 Prompt；旧 Run Resume 使用启动时绑定的 Prompt 版本或快照。

如果产品明确希望旧任务恢复时采用最新策略，也可以，但应把它视为一次显式迁移，并记录"从哪个 Prompt 版本迁移到哪个版本"，否则后续很难解释行为差异。

一个可恢复的 Agent 系统，至少要能回答：这是哪一次 Run？当前在哪个 Step？基于哪个 Task 定义？使用哪个 Agent 版本？使用哪个 Prompt、工具和模型配置？哪些副作用已经发生？

可以把一次 Run 想成一个"执行快照"。Resume 的目标不是拿最新代码重新跑一遍，而是尽可能恢复这个快照，并从确定的位置继续。

所以，一个实用原则是：凡是会改变执行结果、恢复路径或副作用判断的东西，都应该被版本化、快照化，或者至少被明确记录。

Run ID、Step ID、Task Version、Agent Version、Prompt Version 看起来是五个问题，其实是在解决同一件事：让系统知道过去发生了什么，现在应该从哪里继续。

如果你的 Agent 未来要支持长任务、人工审批、失败恢复或跨版本升级，这套身份与版本设计越早建立，后面的迁移成本就越低。