稳定的智能体名称并非你审查的对象：锁定候选体。
代理的名称可以保持不变，而其技能、工具和权限可以更改。应将名称、行为候选项及运行身份分开，以便进行审查和回滚。
两个智能体可以拥有相同的名称，但在影响评估的所有方面却可能存在差异。假设某个“研究智能体”在周一通过了评估。到了周二，其标签仍未改变，但其中一项技能已被替换，某个工具获得了写入权限，而且路由规则使得部分请求通过另一条路径传输。在组织结构图中，它依然被视为同一个智能体。但作为测试结果的依据，这样的描述显然不够精确。
标签仅能指示角色身份，却无法体现促使该智能体通过评估的具体行为组合。随着智能体行为不再局限于单一的模型调用，而是变得由模型、指令、技能、工具、权限、内存策略、路由规则、钩子功能以及主机应用添加的各类组件共同构成，这种差异会愈发明显。
名称用于协调，实例则承载证据
没人希望每次内部修改都会产生一个带有序列号的新公开身份。人们需要一个持久不变的名称。一个由研究代理、依赖代理和支持代理组成的团队，如果能通过标签明确了解每个代理的职能及其定位，会更有帮助。
评估则关注另一个问题：这个判定结果适用于哪一种具体的行为候选者？试想一下，评估是针对某个单一模型、提示词组合、技能集、工具边界、权限策略以及路由设置来进行的。只要这些要素对测量结果有影响，它们就会成为结果描述的一部分。如果更换其中一个要素，旧的结果或许仍能暗示新的候选者，但已无法为其背书。
一个友好的名称正好可以解决这个问题。在其下的可执行组件不断变化时，产品身份依然保持稳定。对人员而言，身份赋予连续性；对候选者而言，身份则带来精确性。
配置正逐渐变成可查看的实体
目前的智能体产品已经展现出这种模式的某些特征，尽管它们之间并未采用统一的架构。某些工具允许用户在文件中定义智能体，这些文件会整合有范围限定的指令、工具、约束条件、选定的技能及MCP服务器，同时还包含模型和权限设置；针对特定项目的定义则可存储在代码仓库中。这虽算是一种设计思路而非标准，但它表明配置不再仅仅是模型调用时的隐式设置，而可以成为可供阅读和审查的实体内容。
另一种模式是将提示词、工具列表、调度计划、凭证以及内存设置都存储在 Git 中，这样任何更改都会通过拉取请求进行，同时留下审查记录、回滚选项以及审计轨迹。虽然有机构采用这种方式，但并不能说明所有团队都应如此做，不过它确实表明智能体行为可以像软件配置一样被管理，并具备类似软件的历史记录功能。
其他一些迹象也指向同一方向。某些提供商平台已经提供了可重复使用、具有版本控制的智能体配置，不过这些接口仍处于测试阶段且仍在不断改进中。协议路线图也将智能体身份列为未来需要处理的主题，这仅是计划而已，并非已实现的功能。这一切都并不意味着问题已经解决。尽管如此，这些例子足以支持这样一个观点：当行为由多个可独立更改的组件构成时，整个系统就需要有自己的标识符。
即使各部分都有版本标识，整体仍可能模糊不清
这就是问题变得令人恼火的地方。模型有版本，技能有修订版，代码仓库有提交记录，MCP服务器有部署版本，内存策略可能有自己的版本，而智能体也可能有对提供者可见的版本。每个组件都可以被命名，但组合后的整体依然难以确定。
来看看固定设置为何会部分失效的情况：
- 提示词被固定，但模型别名发生了变化。
- 模型被固定，但技能会追踪最新版本。
- 技能被固定，但主机应用程序改变了其提供的工具列表。
- 权限策略发生了变化，但公共名称保持不变。
该系统以碎片化版本的形式存在，实际运行的版本却并不明确。软件发布机制可以提供一个有用的类比，但有一个局限：代理配置不一定是单个二进制文件或一个庞大的清单文件。这种类比关注的是决策的适用范围。当存在多个构建版本时，软件团队不会仅仅停留在“我们测试了产品X”这样的表述上。产品名称有助于协调工作，而具体的构建版本或提交记录则能表明该声明所针对的是哪个候选版本。每当配置可能显著改变行为时，代理审查也需要同样的区分方式。
三个标识优于一个
强制让单一标识承担所有含义会很快引发混乱。至少应该将三层内容区分开来。
面向用户的标识
其持久性角色：包括名称、用途、所有者、职责以及在系统中的位置。它必须足够稳定，以便其他人和智能体能够围绕其进行协调。
行为候选体身份
这是团队会评估、批准、比较或发布的、用于塑造行为的各类依赖项的完整集合。根据架构的不同，它可能涉及：
- 正在运行的模型及其会改变行为的各种设置，
- 指令文本或提示词包，
- 绑定到特定版本的技能，
- 它能够访问的工具和MCP服务器，
- 它能够执行的任务以及需要审批的内容，
- 内存的存储与使用方式，
- 路由与交接规则，
- 拦截生命周期事件的钩子，
- 如果会影响行为，则还包括框架或运行时版本，
关键在于“材料”。其目的并非仅仅因为某个设置存在就将其序列化，而是要捕捉那些一旦发生变化就会导致审核、复现或回滚结果出现错误的依赖关系。
执行身份
即便是一个被完美固定的候选项也无法涵盖影响某次执行的所有因素。执行过程还取决于用户输入、可变的内存内容、获取的上下文信息、外部系统状态、实时数据、凭证、人为决策以及模型本身的非确定性。在这些因素起作用的情况下，它们都属于执行过程的组成部分。
将不同层次的内容分开处理，可以避免两种相反的错误：将一个便于识别的名称视为精确的技术身份，或将配置快照当作记录了关于实时执行过程的全部信息的载体。
哪些内容值得固定
固定内容的程度取决于其重要性。低风险的个人助手可能只需记录仓库提交信息或服务提供商版本即可。而具有写入权限的生产工作流则需要更详细的记录。在评估时，应记录所有与测量相关的信息：模型、提示词、技能、工具、权限、路由以及系统状态。
可以先跳过架构部分，使用上述列表作为检查清单。针对每一项，思考在它发生变化后是否仍能称其为经过评估的候选项。如果答案是否定的，那么该项就应该被纳入候选项的身份信息或溯源记录中。
敏感值无需被复制到记录中。配置可以指向密钥引用、凭证类或权限边界，而不会使清单变成新的秘密泄露途径。明确的身份标识应有助于提升可审计性，且不会引发更严重的安全问题。
评估、调试和回滚有一个共同需求
这些看似是三种独立的操作问题，但实际上每一种都需要一个可恢复的对象。
评估。任何分数都是对某一对象的判断。当该对象无法被足够精确地还原时，该分数可能会比它所描述的对象更长久地存在。并非每次修改都会使所有评估失效：修正与某项技能无关的拼写错误几乎不会影响推理能力评估，而权限变更可能不会影响文章质量，却会决定安全审查的结果。关键在于原本要测量的内容，且这一判断必须公开透明，这样才能避免用一个固定的名称掩盖实质上的变化。
调试。在没有配置标识的情况下，调查故障就如同在层层迷雾中探寻。提示文件、控制台历史记录、工具注册表、部署日志、内存快照、分支信息以及运行记录可能各自反映了某一层面的情况，但整体状况依然模糊不清。一个确切的候选版本参考可以简化首要问题：这次出问题的运行确实使用了大家默认的那个候选版本吗？如果是，接下来就需要查看其执行状态和行为；如果不是，这种不一致本身就是一个重要发现。来自公认候选版本的意外情况与从未使用过该候选版本的运行故障属于不同的故障类型。
回滚。假设已批准的候选方案包含了一个提示词、一套技能、一项权限策略、一条路由规则以及一个运行时环境。仅恢复提示词并不能说明旧候选方案已回归。团队应考虑是重新构建整个上次批准的候选方案，还是仅撤销他们注意到的某个组件。前者才是真正的回滚，后者则属于有希望的编辑操作。
还有一点容易被忽视。要找到“最后被接受的候选方案”需要进行查询，而这只有在候选方案带有版本记录时才可行。确切的身份信息可以说明每个候选方案的内容，但无法显示哪个替代了哪个，也无法体现其间发生了什么变化。如果回滚很重要，那么每个候选方案都应标明其前身并列出实质性的差异，这样恢复工作时就无需再四处寻找。
切勿让配置掩盖运行状态
一种诱人的过度处理方式是创建一个包含所有内容的完整快照，但这会带来新的问题。可变内存、检索到的文档、用户输入、外部 API 状态、时间戳以及凭证等都会影响程序的运行。其中有些信息是敏感的，有些需要保持动态变化，还有些无法被精确重现，因此并非所有内容都应包含在候选方案中。
更清晰的划分方式如下：
- 配置层记录了所选择的那些影响行为的依赖项。
- 运行层记录了使用了哪个候选方案以及所有重要的可变输入。
- 审批层记录了最终获得批准的精确候选方案。
这些层次可以相互指向，而不会融合成单一的整体。这样的边界也能防止“完全相同的身份”这种概念膨胀成证据无法支撑的断言。确定某个候选对象并不会让模型变得确定性强、脱离外部系统，或保证日后产生完全相同的输出。它只是让该断言的主题可以被检索到，而这已经非常有帮助了。
五项问题测试
当某个被命名的主体重要到需要被审核或发布时，可以询问：
- 哪些内容可以在不改变名称的情况下发生变化？在大多数系统中，变化的数量比人们预期的要多。
- 这些变化中哪些可能会使这项特定的审核断言失效？这取决于决策涉及的是质量、安全、权限、可靠性、成本还是准备程度。
这一切都并不意味着每次修改都必须经过繁琐流程。当某个决策开始产生实际影响时，就需要精确性。由于智能体行为是在模型之上及其周围构建的，而且这种构建方式逐渐变得模块化、可移植、可版本控制或可替换，配置就不再是偶然的设置，而是可执行候选方案的一部分。名称可以保持不变，但相关证据必须能够显示究竟发生了什么变化。
相关阅读
- 为何智能体准确率指标具有误导性：pass^k、扰动测试与故障注入 — 为何pass@1会掩盖不可靠的AI智能体，以及如何通过pass^k、输入扰动集和故障注入来揭示其在一致性、稳定性及容错能力方面的缺陷。
- 为何在演示中表现出色的智能体在实际应用中会失败，以及应构建何种替代方案 — 失败点分析、单智能体与多智能体之间的权衡、重试与回退等设计实践，以及运行AI智能体除了代币费用之外的全部成本构成。