概念/概念定义
机械状态平面与 Provenance 来源坐标
出自东方屹腾执行型 Agent 落地（案例提供 梁博）
概念定义
机械状态平面是执行型 Agent 运行态上下文里专管业务 API 参数的那一层。它把状态值的读写、绑定和传递从 LLM 参与的内容里彻底分离出来，让每一步 API 的入参都有一个唯一、可审计、可 fail-fast 的机械来源，而不是由会漂移的模型当场生成。
可以把它想象成 Agent 启动时就砌好的一整墙小格子。每个格子对应一个机械参数，格子的键由两部分共同确定：参数的供给者是哪个工具，以及它产出在哪个运行时环节。沿着会话的时间轴，每个格子只维护这个参数的最新值。谁要用某个状态，就自己去对应的格子里读，不再从一长段叙事上下文里让模型猜。运行态里每个参数都对应一个 Provenance 结构体，它由各项规范和描述解析组装成一个唯一坐标，即键名加作用域加供给者加产出层级。读写都以这个坐标为准，参数的归属和取值因此始终明确。
使用说明
它防住的失败很具体。薪资组搭建的第一步会调模板匹配接口，匹配成功后返回一个 template_id，下游导入模板时必须原样以这个 id 作入参。问题在于企业里的各种 id 普遍是雪花算法生成的 64 位甚至 128 位随机字符串。让模型读完对话后准确原样复述这种 id，要求它把每一位字符都还原正确、一位都不能错，这件事到今天的模型仍然做不到。原因在于 LLM 是无状态的概率函数：即便在上下文里告诉它 id 的值，它也不会按值取用你的参数，只会尝试重新生成一串近似的字符。在这个场景里，id 缺一位会校验失败，错一位更糟——Agent 可能执行「成功」，业务数据却被悄悄改坏，期望的状态改变并没有发生。
东方屹腾早期踩过这个坑。任务之间还停留在类 MCP 的形式，第一个任务调成功后把结果组装进对话上下文，让第二个任务从最新上下文里解析绑定参数。旅行助手用这种方式没有问题，因为它传递的是 city、天气这类文本，语义偏差不致命。换到机械参数严格绑定的场景，实测下来极度不可靠，有时成功有时失败，什么时候失败既不可控也无法预料。解法是把机械状态平面单独划出来，参数值在各执行环节根据工具调用回执机械性地准确维护。这样原有的 SaaS API 一行都不用改，只要经网关暴露出来就能被 Agent 按场景灵活编排，连贯调用任意数量的接口，不会再发生参数绑定的错误。
这套解法能成立有一个前提：系统是企业级封闭体系，所有工具都由团队自己管理和注册，不需要也不希望用户任意接入外部工具。正因如此，Agent 启动时就能确定它所感知世界里全部可能的状态键字典，把每个参数的坐标钉死。
何时需要
当你的 Agent 在执行一连串有严格状态依赖的业务流程，步骤之间传递的是 id、状态码这类机械参数，而错一位就会破坏数据或造成假成功。把整个运行态上下文按职责分开，就是会话统一状态平面的三权分立；机械参数所服务的任务调度本身，由任务 DAG 与状态机维护；它和叙事内容、控制信号的根本分野，见控制平面与叙事平面的二元论。