“这份资料已经处理了。”在项目群里，这句话通常会让人放心；在一个由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；候选资料确实属于 V2；必要字段已经人工确认；操作者身份有效且拥有保存核验结果的权限；该请求尚未被成功处理。任一条件不满足，都不应悄悄换成“尽力保存”。

权限要按动作而不是按人名表达。采购员可以确认资料，不代表能审批；资料核验员可以保存核验结果，不代表能创建订单；Agent可以提交动作请求，不代表拥有绕过人工确认的权限。对FDE来说，把权限放进动作约定，才能让业务规则在接口、界面和人工操作中保持一致。

接着写状态变化。本动作成功后，A-017 V2 的“资料核验状态”从“待核验”变为“已核验”，并新增一条核验记录；候选资料不被覆盖，确认资料与来源保留引用。如果确认不完整，状态应为“待补充”或“部分确认”，不能直接标记“已核验”。

副作用也要列出。保存核验结果会不会通知采购经理？会不会产生待办？会不会修改下游系统？本案例中，保存只写入申请与核验记录，并可生成待审批提醒；不创建订单、不扣库存、不替代审批。把“不发生什么”写出来，是控制范围扩张的有效方式。

“接口返回成功”不是业务成功。业务成功的证据是目标记录 A-017 V2 已经出现指定的核验结果，并且能读取到对应的确认人、时间、来源和请求ID。FDE要在动作卡里明确：成功结果返回什么记录标识；失败结果带什么原因；未知结果如何处理。

失败与未知不同。权限不足、版本不匹配、缺少确认依据，是明确失败，系统应告诉操作者缺什么、不能继续做什么。网络中断或下游写入超时则可能是未知：请求也许已经写入，也许没有。这时不能让Agent盲目重试，因为重复写入可能造成两条核验记录或重复触发通知。正确动作是先按请求ID查询目标记录或动作历史，再决定是否补做。

审计记录至少保留：业务请求ID、目标对象与版本、输入摘要和来源引用、操作者身份、触发时间、规则检查结果、执行结果、返回记录ID、异常原因和后续处理人。日志不是为了“留一份系统记录”，而是为了回答一次争议：谁以什么依据把什么状态变成了什么，系统最终有没有写进去。

设计完成后，不要只测一条“正常数据”。请业务和研发一起走四种请求。

第一种是正常请求：A-017 V2、资料完整、确认人有效、请求ID新。预期是写入一条核验记录，状态变为已核验，返回的记录可以被重新读取。

第二种是部分确认：数量确认了，交期没有确认。预期不是“尽量完成”，而是保留候选、写明待补充字段，状态停在部分确认或待补充，并把问题交回对应角色。

第三种是旧版本请求：附件与候选信息来自 V1，当前申请已变为 V2。预期是拒绝写入并提示版本冲突，不能把旧资料覆盖到新版本。

第四种是无权限请求：界面显示某人是项目成员，但其可信身份没有保存动作权限。预期是明确拒绝，记录权限检查结果；系统不能因为用户“看起来在项目里”就放行。

还应单独练一次未知结果：模拟调用返回超时。操作者先查询请求ID和目标记录；只有确认没有执行过，才允许重新发起。这里不假设所有系统都有原子事务能力，动作设计的目标是让不确定性可识别、可查询、可交接。

这套方法可以迁移到服务工单：把“保存资料核验结果”换成“保存问题确认结果”，把“审批”换成“指派处理人”，把“实际完成”换成“关闭工单”。依然要把建议、确认、执行和回执分开。

Agent最适合帮助理解资料、生成候选和组织交互；当它准备改变业务记录时，动作约定就是它不能越过的边界。下一篇将把这些对象、动作和系统连接画进一张可读的系统图。

让Agent执行业务前，先把动作约定写清楚

副总裁

人工智能

FDE岗位实务指南解析：以采购申请A-017V2为例，详解Agent业务动作拆解为可核验约定的方法。涵盖目标对象定义、输入依据、权限控制、状态变化、异常处理及四种请求测试，确保业务操作可追踪、可审计，防止“已处理”模糊表述导致的风险。

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

让Agent执行业务前，先把动作约定写清楚

让Agent执行业务前，先把动作约定写清楚

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐