FDE岗位实务指南 · 第11篇
“这份资料已经处理了。”在项目群里，这句话通常会让人放心；在一个由Agent参与的业务流程里，它几乎没有可执行含义。它可能表示资料被读过、候选信息被抽取、人工已经确认、核验结果被保存，也可能表示订单已经提交。每一种动作的风险和后果都不同。
FDE的责任，不是把一句自然语言翻译成一个按钮，而是把业务动作拆成可核验的约定：对谁做什么，依据是什么，谁有权做，什么算成功，遇到异常怎么办。没有这份约定，Agent即使回答得很像，也可能在错误对象上完成一次“正确”的操作。
本文仍使用澄川制造的教学案例。采购申请 A-017 当前为 V2 版本，业务希望Agent协助保存一次资料核验结果。这里的动作只限于“保存本次资料核验结果”，不包含采购审批，也不包含下单。把范围钉住，是动作设计的第一步。
一句“已处理”可能掩盖哪些不同动作
先把群消息翻译成可能发生的业务事实。Agent收到附件后提取供应商名称、数量和交期，这是生成候选信息；采购员查看候选信息并确认，这是形成确认；系统把确认结果写入 A-017 V2，这是保存核验结果；采购经理在权限范围内同意申请，是审批；采购系统创建可执行订单，才是下单。
这五件事不能用“已处理”代替。候选信息可以错，确认可能被撤回，保存可能失败，审批与下单更涉及授权和外部影响。若前端只显示一个绿色成功提示，业务人员会以为订单已推进，实际可能只是模型把一段文字放进了草稿区。
动作拆分还解决责任问题。谁对候选内容负责？系统要保留来源文件和抽取版本。谁对确认负责？必须是有业务身份的确认人。谁对实际写回负责？需要可信身份和目标记录的权限。把责任写清，后续排错不必回到“当时谁点了什么”。
因此，FDE先把动词写成业务名词化的句子：保存“哪一次、哪条申请、哪一版、由谁确认”的资料核验结果。若一句话仍然无法区分目标、版本或结果，它还不够资格交给Agent执行。
写清目标对象与输入依据
动作卡的第一栏是目标对象。这里不是笼统的“采购申请”，而是采购申请 A-017 的版本 V2。A-017 是业务身份，V2 是此刻被核验的版本；系统里可能还有一个内部记录ID，它用于写入定位，但不能取代业务身份。
第二栏是输入。最少包括：申请ID与版本、待处理的候选资料、候选资料的来源文件或来源记录、人工确认后的证据、操作者的可信身份、以及本次业务请求ID。输入中最容易被省略的是“确认后的证据”。没有它，系统只能知道模型提出过什么，无法知道业务人员到底同意了哪一项。
可以用三层状态管理资料：原始资料保留原貌；候选资料带上抽取时间、模型版本和来源；确认资料带确认人、确认时间和确认范围。三层并存不是形式主义。供应商把附件换成新版本时，FDE必须能解释：现在保存的是哪一版候选，确认是否仍有效，旧资料有没有影响判断。
下面是一张足够小但可以开发与测试的输入清单：
项目 | A-017 V2 的约定 |
目标 | 采购申请 A-017，版本 V2，对应内部记录ID |
原始资料 | 供应商附件及其来源链接或文件标识 |
候选资料 | Agent抽取的名称、数量、交期，带抽取版本 |
确认依据 | 采购员确认的字段集、确认时间和说明 |
操作身份 | 由受信任身份服务提供的操作人 |
请求标识 | 用于去重、追踪和审计的业务请求ID |
不要让模型自报“我是采购员”成为身份依据；也不要把界面上显示的角色直接等同于后台调用身份。界面角色是体验层信息，真正能调用写接口的身份、权限范围和授权时效，要由身份与权限机制验证。
补齐前提、权限与状态变化
输入齐了，动作仍不能执行。动作卡还要写前提条件：A-017 当前仍是 V2；候选资料确实属于 V2；必要字段已经人工确认；操作者身份有效且拥有保存核验结果的权限；该请求尚未被成功处理。任一条件不满足，都不应悄悄换成“尽力保存”。
权限要按动作而不是按人名表达。采购员可以确认资料，不代表能审批；资料核验员可以保存核验结果，不代表能创建订单；Agent可以提交动作请求，不代表拥有绕过人工确认的权限。对FDE来说，把权限放进动作约定，才能让业务规则在接口、界面和人工操作中保持一致。
接着写状态变化。本动作成功后，A-017 V2 的“资料核验状态”从“待核验”变为“已核验”，并新增一条核验记录；候选资料不被覆盖，确认资料与来源保留引用。如果确认不完整，状态应为“待补充”或“部分确认”，不能直接标记“已核验”。
副作用也要列出。保存核验结果会不会通知采购经理？会不会产生待办？会不会修改下游系统？本案例中，保存只写入申请与核验记录，并可生成待审批提醒；不创建订单、不扣库存、不替代审批。把“不发生什么”写出来，是控制范围扩张的有效方式。
定义结果、异常与审计记录
“接口返回成功”不是业务成功。业务成功的证据是目标记录 A-017 V2 已经出现指定的核验结果，并且能读取到对应的确认人、时间、来源和请求ID。FDE要在动作卡里明确：成功结果返回什么记录标识；失败结果带什么原因；未知结果如何处理。
失败与未知不同。权限不足、版本不匹配、缺少确认依据，是明确失败，系统应告诉操作者缺什么、不能继续做什么。网络中断或下游写入超时则可能是未知：请求也许已经写入，也许没有。这时不能让Agent盲目重试，因为重复写入可能造成两条核验记录或重复触发通知。正确动作是先按请求ID查询目标记录或动作历史，再决定是否补做。
审计记录至少保留：业务请求ID、目标对象与版本、输入摘要和来源引用、操作者身份、触发时间、规则检查结果、执行结果、返回记录ID、异常原因和后续处理人。日志不是为了“留一份系统记录”，而是为了回答一次争议：谁以什么依据把什么状态变成了什么，系统最终有没有写进去。
可用一张动作卡收束：
栏目 | 保存资料核验结果 |
对象 | A-017 V2 及其核验记录 |
输入 | 已确认资料、来源、可信身份、请求ID |
前提与权限 | 版本匹配、资料完整、身份与动作权限有效 |
状态与副作用 | 待核验→已核验；新增记录；不审批、不下单 |
结果与异常 | 返回实际记录；失败可解释；未知先查询 |
审计与交接 | 全程留痕，必要时交回人工处理 |
用四种请求检查动作约定
设计完成后，不要只测一条“正常数据”。请业务和研发一起走四种请求。
第一种是正常请求：A-017 V2、资料完整、确认人有效、请求ID新。预期是写入一条核验记录，状态变为已核验，返回的记录可以被重新读取。
第二种是部分确认：数量确认了，交期没有确认。预期不是“尽量完成”，而是保留候选、写明待补充字段，状态停在部分确认或待补充，并把问题交回对应角色。
第三种是旧版本请求：附件与候选信息来自 V1，当前申请已变为 V2。预期是拒绝写入并提示版本冲突，不能把旧资料覆盖到新版本。
第四种是无权限请求：界面显示某人是项目成员，但其可信身份没有保存动作权限。预期是明确拒绝，记录权限检查结果；系统不能因为用户“看起来在项目里”就放行。
还应单独练一次未知结果：模拟调用返回超时。操作者先查询请求ID和目标记录；只有确认没有执行过，才允许重新发起。这里不假设所有系统都有原子事务能力，动作设计的目标是让不确定性可识别、可查询、可交接。
这套方法可以迁移到服务工单：把“保存资料核验结果”换成“保存问题确认结果”，把“审批”换成“指派处理人”，把“实际完成”换成“关闭工单”。依然要把建议、确认、执行和回执分开。
Agent最适合帮助理解资料、生成候选和组织交互；当它准备改变业务记录时，动作约定就是它不能越过的边界。下一篇将把这些对象、动作和系统连接画进一张可读的系统图。
