假设 ERP 已经提供了一个“创建补货单”的 API。接口文档写得很清楚：传入物料编码、仓库编码、补货数量和期望到货日期，系统就会返回一张新单据的编号。

技术上，这个接口已经可以被 Agent 调用。但业务上，它还远没有准备好。

Agent 是否找对了物料和仓库？库存项是否真的存在缺货风险？物料是否启用，仓库是否冻结？是否已有未关闭补货单？建议数量来自哪个版本，用户有没有权调整？超出阈值时由谁批准？

更麻烦的是执行过程。接口超时后应该重试吗？第一次请求可能已经成功，只是返回丢失；盲目重试，可能创建两张补货单。若单据已写入 ERP，之后发现错误，又该删除、作废还是变更？

这些问题，API 文档通常不会替企业回答。

敲黑板：API 解决“怎么连接”，行动能力解决“在什么业务条件下，由谁，以什么责任执行什么动作”。只有把接口包进业务语义、权限、规则、风险、补偿和证据中，它才适合成为 Agent 可以调用的企业行动。

API 关心协议、参数、返回值和服务稳定性。它能说明怎样新增记录，却未必知道业务上为什么应该创建。

如果直接把接口暴露给 Agent，至少会出现五类风险。

第一，意图错位。用户说“准备一下补货方案”，Agent 却把“准备方案”理解成“正式提交采购”。自然语言中的建议、草稿、提交和下发，业务后果完全不同。

第二，对象错位。用户正在查看物料 A，Agent 却从对话中提取了另一个仓库或旧物料编码。接口只校验编码存在，不会确认它是不是当前场景中的正确对象。

第三，权限错位。集成账号也许拥有较高系统权限，但提出请求的用户未必有权为该组织、仓库或金额创建单据。使用一个超级账号代替所有人的业务身份，会让授权边界消失。

第四，状态错位。物料已停用、仓库被冻结、补货单已存在，或者判断所用需求版本已经过期，接口仍可能接受格式正确的参数。

第五，结果错位。HTTP 返回成功，可能只表示请求已接收；接口超时，也不代表业务一定失败。若系统没有后续查询、回写和去重机制，Agent 无法知道业务世界究竟发生了什么。

所以，“可以调用”不等于“可以安全执行”。裸 API 是技术入口，行动能力才是企业执行入口。

二、先定义业务动作，再映射接口和工作流

行动建模应从业务动词开始，而不是从接口列表开始。

例如，补货过程中至少可以区分四个动作：创建补货草稿、提交补货单、审批补货单、下发采购申请。它们可能连接同一套 ERP 接口，却有不同的意图、权限、前置条件和风险等级。

“创建补货草稿”只是把风险判断转成待确认记录；“提交补货单”会改变对象状态并进入流程；“审批补货单”代表责任人认可；“下发采购申请”则开始改变外部权威系统中的交易事实。

如果把这些步骤都包装成一个“完成补货”动作，任何一步失败都会难以判断责任，也难以设计回退。更合理的方式，是把业务上自然、责任边界清楚的动作分别定义，再由工作流或事件机制组织长流程。

业务动作定义后，再决定底层用 API、工作流节点、消息、RPA 还是人工任务实现。技术可以替换，业务语义应保持稳定。同一个动作可被页面、Agent 或定时任务调用，但必须经过同一套权限、规则和证据机制。

三、行动契约：九项内容共同定义一个动作

为了把动作从技术接口提升为企业能力，把动作模板、风险分级、失败处理和写回要求，重构为一份“行动契约”。

契约不是一份法律文本，而是行动提供方与调用方之间的业务约定：Agent 可以请求什么，服务端必须检查什么，执行后要返回和记录什么。

1. 意图：这个动作要完成什么业务结果

动作名称应使用业务动词加业务对象，例如“创建补货草稿”“提交补货单”，而不是 

意图要说明完成动作后，业务世界应该发生什么变化。“创建补货草稿”的结果是生成一条可确认的补货记录，不等同于正式采购，也不自动承诺供应商。

动作必须绑定明确的对象实例及必要关系。创建补货单作用于哪一个库存项、物料、仓库和组织？提交审批作用于哪一张补货单？

对象应优先来自当前本体上下文，而不是让 Agent 再次用自由文本填写。这样可以避免用户正在处理物料 A，参数却误传成物料 B。

3. 参数：哪些由系统带入，哪些允许调整

参数需要有业务名称、类型、来源、范围和校验规则。物料和仓库可以从对象上下文带入；建议数量来自逻辑层；实际申请数量允许计划员调整，但必须说明调整理由并受上下限约束。

能用对象引用、数值、日期、枚举表达的内容，不应全部退化成自由文本。结构化参数既方便校验，也便于审计和复用。

4. 前置条件：什么情况下才允许提交

前置条件不是提示语，而应由动作服务在执行前强制检查。例如：物料处于启用状态，仓库可用，申请数量大于零，不存在未关闭的重复补货单，风险判断仍在有效期内。

即使 Agent 认为条件已经满足，服务端也要重新校验。调用方的理解不能替代企业的执行规则。

5. 权限：谁能看、谁能发起、谁能批准

权限不只判断“这个人能不能调用 API”，还要约束他能对哪些组织、仓库、对象和金额执行哪一步动作。

Agent 应继承用户或受托角色的业务身份，而不是借用集成账号的全部权限。计划员可以创建草稿，采购经理可以批准一定额度，跨组织或超额度动作则进入更高层级审批。

6. 风险等级：动作需要多强的控制

风险取决于它是否写入外部权威系统、是否影响资金库存和客户权益、能否回退、影响对象数量，以及是否会触发现实世界活动。

同一个业务意图也可能有不同风险：“生成补货建议”风险较低，“提交补货单”风险居中，“自动下发大额采购申请”风险较高。风险等级决定自动化、确认和审计的强度。

7. 执行结果：成功之后究竟改变了什么

结果不能只有“成功”或“失败”。契约应说明创建或修改了哪些对象、属性、关系和状态，是否写入外部系统，返回了什么业务编号。

对于创建补货单，成功结果可以是：生成补货单号，状态进入待审批，关联库存项、物料和仓库，并记录外部系统是否已经受理。

8. 补偿：出错后怎样撤销、抵消或人工处置

尚未产生外部影响的草稿可以直接取消；已经下发 ERP 的采购申请，通常不能靠删除本体记录回滚，而要执行“作废采购申请”或“发起采购变更”；已经发送的客户消息无法真正撤回，只能登记误触达、启动补救并保留记录。

补偿动作应与主动作一起设计，尤其是高风险和不可逆动作。

行动证据应记录发起人和代理 Agent、执行时间、对象、输入参数、判断依据与版本、权限校验、审批意见、幂等标识、外部返回、失败原因、重试和补偿记录。

证据不是系统运维日志的替代品，而是业务可以理解的行动记录：谁基于什么理由，对哪个对象做了什么，最后产生了什么结果。

九项合在一起，行动能力才形成完整契约。少一项，Agent 都可能在执行时遇到一个没有业务答案的问题。

四、风险不同，自动化边界也不同

行动建模不是把所有动作都交给 Agent，也不是给所有动作增加多级审批。更合理的做法，是让治理强度与业务风险匹配。

低风险：可以自动执行，但必须留痕

添加备注、标记关注、创建建议草稿、发送内部提醒等动作，不改变核心交易事实，影响范围有限。Agent 可以在基础权限和参数校验后自动执行，但仍要记录对象、调用人、时间和结果。

中风险：Agent 预填，人确认后提交

提交补货单、分配客户经理、更新运营阶段等动作会改变对象状态，但影响通常可控。Agent 可以整理上下文、预填参数和解释依据，由责任人确认后提交；必要时填写调整原因。

高风险：Agent 建议，审批链负责授权

下发采购申请、冻结库存批次、批量客户触达、修改生产计划等动作，会影响资金、库存、客户权益或现实运营。Agent 更适合做风险判断、方案生成和参数预填，正式执行应经过明确审批、提交条件、强审计和补偿设计。

极高影响、批量且难以回退的动作，可以进一步要求双人复核、小范围演练或禁止 Agent 直接提交。

风险分级不是永久标签。动作金额、批量范围、对象类型、调用身份和业务时段变化，都可能使同一个动作进入不同控制档位。行动契约应在每次请求中计算适用边界，而不是只在设计时贴一次标签。

五、超时不是失败，重试也不是重新来一次

Agent 执行动作时，最危险的时刻往往不是明确报错，而是“不知道成功了没有”。

假设下发采购申请后 ERP 超时。本体没有收到申请编号，但 ERP 可能已经创建成功。如果立即重试，可能产生重复单据；如果直接标记失败，又会让两个系统的事实分裂。

因此，高影响动作需要幂等设计。每次业务请求生成稳定的幂等标识，例如由补货单和动作请求共同确定。相同请求再次到达时，外部系统应返回已有结果或当前状态，而不是重复创建。

动作状态也不应只有成功和失败。至少要能表达待校验、执行中、成功、失败、结果未知、补偿中和已补偿。超时首先进入“结果未知”或“执行中”，系统应使用幂等标识查询外部结果，再决定重试或补录。

失败本身也是业务事实。参数错误、权限拒绝、外部服务不可用、部分成功和回写失败，应有不同状态与处理策略。

这里还要区分撤销与补偿。撤销是在外部影响发生前停止动作；补偿是在影响已经发生后，用新的业务动作抵消或修正原结果。补偿不会抹掉原行动，原请求、错误原因和修正过程都要保留。

六、动作完成后，必须产生结果事件

一次行动不能停在接口返回。它必须生成业务可理解的结果事件，并回写对象世界。

例如“创建补货单成功”事件可以携带补货单号、库存项、申请数量、发起人、审批状态和外部系统编号。它会把补货单状态更新为待审批，建立补货单与库存项、物料、仓库的关系，并触发下一步工作流。

如果动作失败，也应生成“创建补货单失败”或“结果待确认”事件，记录失败阶段、错误原因、重试条件和责任人。否则，失败只留在技术日志中，业务人员不知道任务为什么没有继续。

谁是权威来源也要明确。补货建议和判断依据可以由本体维护；正式采购申请号和执行状态如果以 ERP 为准，就必须在 ERP 成功后回传。本体负责上下文、校验、审批和证据，外部系统负责交易事实，双方通过业务编号和结果事件保持一致。

结果回写有三项作用：让对象状态反映最新现实，让后续判断避免重复动作，也让企业能够评估这项行动是否真的解决了最初的问题。

只有“请求—执行—结果事件—对象回写”走完，行动才算闭环。

七、换个角度看：行动建模是在把权限切细

有人担心，一旦企业为 Agent 建设行动层，就等于给 AI 开放更多系统权限。事实上，设计良好的行动层做的是相反的事。

裸接口往往依赖一个高权限集成账号；行动契约则把权限切成具体业务动作：谁可以为哪个组织、哪类对象、在什么额度和状态下创建草稿，谁可以提交，谁可以批准，谁只能查看结果。

Agent 得到的不是“修改 ERP”的宽泛权限，而是“在用户授权范围内，为满足条件的库存项创建一张待确认补货草稿”这样的窄能力。

同时，每次调用都会留下意图、对象、参数、依据、审批和结果。权限不再只是静态角色配置，而成为可以观察、回放和调整的运行边界。

行动建模的目标不是让 Agent 做得更多，而是让企业清楚地决定：它在什么条件下可以做哪一步，做完后怎样知道结果。

同一请求重复执行会不会产生重复业务结果？

失败和补偿是否同样会生成事件并回写？

如果这三个问题没有答案，动作还不适合开放给 Agent。

结语：把执行权装进契约，而不是装进提示词

API 让系统可以连接，行动能力让连接进入企业责任体系。

一个成熟的业务动作，不只是接口地址和 JSON 参数，而是一份行动契约：它有明确意图和作用对象，有结构化参数、前置条件和权限，有与风险匹配的自动化边界，也有执行结果、补偿路径和完整证据。

Agent 可以理解用户意图、组织上下文、选择动作和预填参数，但真正的执行必须经过契约。这样，企业开放的不是一片模糊权限，而是一组边界清楚、可以测试、可以观察、可以追责的业务能力。

到这里，我们已经依次完成事件、对象、关系、判断和行动的建模。

API 不等于行动：怎样封装一个受控业务动作

API 解决“怎么连接”，行动能力解决“在什么业务条件下，由谁，以什么责任执行什么动作”。只有把接口包进业务语义、权限、规则、风险、补偿和证据中，它才适合成为 Agent 可以调用的企业行动。

副总裁

编程语言

架构设计

后端

ERP系统API接口虽可实现补货单创建，但业务层面存在诸多风险：物料仓库匹配、库存状态、权限审批等关键问题需解决。企业需将API封装为业务动作，建立包含意图、对象、权限、风险控制的行动契约，确保Agent调用安全可控。行动建模需区分草稿创建、提交审批等不同风险等级动作，实现业务闭环管理。

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

API 不等于行动：怎样封装一个受控业务动作

API 不等于行动：怎样封装一个受控业务动作

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐