一次报修从提交到关单，中间要经过设备定位、故障判定、派工、诊断、备件领用、委外审批、完工验收与成本归集。 承担这些环节的是14 个各有职责边界的 Agent：每个 Agent 承担一类任务，通过统一执行管道调用动作契约， 不直接操作数据库；复杂任务被拆为若干可独立校验的步骤，每一步的输入与输出均可追溯； 高危动作在动作定义上标注需人工确认，未携带确认一律拒绝执行；无论调用方是控制台还是外部 Agent，审计写入同一处。
AI 不是一个对话入口，而是一条有职责边界的协作管线。这一判断需要落到一次具体业务上才成立， 因此本文以一次设备故障维修为例，把管线经过的环节逐段说明。
车间设备停机，值班人员在移动端扫码报修，设备编号、位置与故障现象随照片一并进入系统。 系统侧先确定这是哪台设备、属于哪一类故障，生成故障单；随后按设备与故障类型确定处理人与通知渠道； 工程师到场诊断，可调用三层故障知识与知识库检索取得处置建议，再判断自修或转委外。 若转委外，委外维修单由故障单触发，报价上传后进入审批。维修过程登记备件时， 备件出库从工单发起，工单未建立，库存即无法变动。维修完成后经过故障验收、关闭工单。 关单并不是终点：知识被提取入库，备件消耗与维修费用按工单归集到设备与成本中心。
上述环节没有任何一步由单次模型调用完成，也没有任何一步由某一个模块包办。 系统内承担这些环节的是 14 个 Agent，每个 Agent 承担一类任务，边界互不重叠， 执行时统一经执行管道落到动作契约上。
前两段确立设备与故障单，第三段确定处理人与通知渠道；中间三段在工单执行期间发生； 末两段发生在关单之时与关单之后。
| 环节 | 承担者 | 落到哪个动作 |
|---|---|---|
| 报修受理与故障录入 | intent.agent.ts——意图识别三层策略 |
故障上报录入 |
| 设备定位与台账查询 | equipment.agent.ts——设备台账操作与设备画像 |
设备检索 |
| 派工与通知 | 通知分发——候选接收人、模型决策、渠道过滤依次执行 | 故障单分派 |
| 诊断建议 | rag.ts、external-knowledge.agent.ts——故障知识检索与外部知识检索增强 |
知识检索 |
| 备件领用与出库 | inventory.agent.ts——库存查询、备件推荐与出入库 |
工单驱动的出库 |
| 完工验收与关单 | fault.agent.ts、maintenance.agent.ts——故障上报、查询与分派，维护工单操作 |
工单关闭 |
| 成本归集与报表 | analytics.agent.ts——报表生成与数据统计 |
费用按工单归集 |
口径：组件名称与职责取自技术系列《EAMX 2.0 技术架构全景》中的组件表；系统内共 14 个 Agent，该表列出其中承担主要职责的组件，完整清单以系统导出为准。
从收到一句话到动作执行，中间是一条固定管线。管线的入口只负责编排： 决定阶段之间的顺序与数据在阶段之间如何传递，不决定阶段内部如何实现。 阶段划分为四段，顺序固定。
意图识别在这四段之前完成，超出预算即转入兜底分类，不阻塞主流程； 学习回写在工具调用发生时异步触发，不进入当次请求的返回值。
这一划分的作用在于边界可见。上下文构建把系统提示、实体信息与意图模式拼装为一次推理的输入； 图片预处理把照片转为文字摘要后拼入上下文；推理与工具调用阶段由模型在工具清单内发起调用； 学习回写记录本次表达与已解析意图的对应关系，供后续同类请求直接命中。 任一段改动，只需确认该段的输入与输出未变，不必通读整条管线。
编排与执行分开之后，权限判定发生在工具清单的生成环节，而不是在动作执行之后。 进入模型之前，工具清单已经按当前身份的权限过滤完毕，模型的选择范围里不会出现无权调用的操作； 清单由服务端按账号权限生成，客户端拿到的即为服务端的授权结果，只读角色的清单中不含写操作。
依据：管线阶段划分与工具清单的过滤时机取自技术系列《AI Pipeline 编排器》与《EAMX 2.0 技术架构全景》的实现记录。
管线拆解之后，每一个步骤都有明确的输入与输出，产物以结构化卡片交付： 动态表单、故障单、设备列表各成一体，界面按卡片类型渲染，不依赖前端的额外约定。
以设备建卡为例，识别出的字段携带来源与置信度：取自铭牌或合同文档的字段置信度较高， 来自历史数据推断的字段置信度中等，未被映射的技术参数单列存放。 使用者按颜色决定核对范围，不必整表复核。建档时间由 30 分钟缩短至 5 分钟， 铭牌识别单张延迟由 130 秒降至 3–8 秒。
步骤可独立校验的价值在于复核成本。改动某一环节时，只需确认该环节的输入与输出未发生变化； 出现异常时，可以定位到具体一步，而不必在整条管线上排查。
登录页内演示账号，由贵方 AI 助手自行报出工具清单，与站内所述的动作契约总数和业务域覆盖逐项比对， 无需采信本文陈述。查看核验方式 →
一次维修之中，人工介入发生在三处，且三处都不是可选项。
第三项的落点在接口层。审批判定不写在业务函数之中，而是以拦截方式注册在业务事件上： 门槛判定通过后创建审批单并中断主流程，批准之后重新执行原操作。 由此产生的性质是，审批路径与调用通道彼此独立——控制台提交的单据、内嵌助手发起的操作、 外部 Agent 调用的动作，判定标准一致。
人在环在接口层实现，属强约束，而非操作规范。动作定义中没有确认参数的高危动作， 无论由哪一条通道发起都不会执行；换一条通道并不构成绕过方式。
动作契约同一份，投影为三条通道：Web 控制台由业务人员使用，身份来自登录会话； 内嵌助手按请求级上下文授权；外部 Agent 以接入凭证调用的方式使用同一批动作。 三条通道的身份来源不同，权限裁决与审计口径相同。
审计记录通道、身份、动作、参数与结果，写在同一个位置。事后可以回答 「该条资产状态由谁、在何时、通过哪条通道修改」，包括由 Agent 代为操作的情形。 执行管道内另有两项机制用于消除重复与误判：预演在执行前返回将要发生的结果且不产生写入， 使审批人看到的是预演结果；幂等键使同一次调用重复提交只生效一次， Agent 的重试与网络抖动不会造成重复入账。
能力边界在接口层即已确定。动作契约合计 247 条，覆盖 35 个业务域； 每条动作是否可达由服务端按账号权限裁决，只读角色的工具清单中不含写操作， 客户端拿到的清单即为服务端的授权结果。
口径：动作契约 247 条、业务域 35 个、该账号可见工具数由系统实时返回，均为系统当前状态的导出结果，可由演示环境实时核验，会随版本迭代变化。
工单关闭时，模型从维修过程中提取结构化的知识对，内容包括故障模式、根因、处置方案、关键备件与维修时长五项， 写入知识库。同类故障再次发生时，诊断环节可以先检索历史处置记录，而不是从零开始推断。 三层故障知识与检索增强的组合，使故障诊断时间缩短 70%。
同一时刻发生的另一件事是成本归集。备件消耗按工单归集到设备与成本中心， 成为单台资产运维成本的一项；实物账与财务账同源，使「修还是换」具备可计算的依据。 知识留在系统里，费用的去向留在账上，这两项是关单之后真正的产出。
需要说明边界：上述机制不构成对全自动与无人值守的承诺。识别结果需人工复核的情形仍然存在， 超出动作清单范围的请求会被拒绝执行，高危动作始终保留人工确认环节。