Skip to main content
此为预览文档,正式版本尚未发布。
客服收到“订单迟迟未发货,希望明天收到”的请求。订单、库存、物流和售后 Agent 分别查证,由履约协调 Agent 组织处置,再核对业务系统中的真实结果。这类流程能减少人工跨系统查询与转派,也能把原因、决策和执行记录留在同一项工作中。 本案例的五个 Agent 都用 AgentScope Java 开发并注册为 External Agent,包括 Leader。每个应用独立部署,Service 负责目录、派发、团队协作与执行观察;企业系统仍负责业务规则和数据。

准备业务资料与接入环境

下载固定业务数据,保存为 business-data.json。它包含三张虚构订单、库存、物流和政策,用于开发工具与核对结果,不是已部署的 OMS/WMS/TMS 服务,也不包含完整 Agent 应用。 准备 Java 17+、配套版本的 AgentScope SDK 与 agentscope-extensions-aistio、可用模型、Service 地址,以及允许注册到目标 Namespace 的应用凭据。标准 Service 部署优先采用 Java HTTP 注册与合约 先让应用工具从固定数据读取,完成单任务验证,再接入真实 OMS、WMS、TMS 与售后 API。所有角色收到的订单号要在业务系统按调用者授权校验;请求中的 customerId 本身不是身份凭据。

1. 开发五个业务 Agent

将工具实现为 AgentScope Toolkit 中的业务函数,再交给各应用的 Agent。下面是示例应用工具契约,不是 Service 内置 API;工具名和返回字段由你在应用中实现: 诊断阶段只使用读取工具。创建处理单或变更订单时,业务服务必须检查批准记录、订单版本和动作内容;不能把模型输出“approved”当作授权,也不能以生成的自然语言编号充当真实处理单。

2. 接入任务能力

每个 Agent 使用独立 agentKey,副本使用稳定且不同的 instanceKey。在现有应用的初始化代码中接入如下片段:
这是接入片段:catalogAgent 是应用的目录 Agent;taskAgentFactory 是返回具备该角色模型、工具、指令和隔离上下文的 Supplier<HarnessAgent>config注册指南配置 HTTP 地址、范围和凭据。controlUrlserviceToken 由管理员提供给可信应用后端,不传给 Endpoint 调用方。 HarnessAgentTaskStarter 负责接入任务上下文、协作动作与结果回传。业务工具仍需自行实现;每次执行不能共享可变的对话状态。Leader 还必须正确使用可用的委派与协调节点完成能力。先分别验证成功、失败、取消与并发隔离,再组 Team。仅 Aistio.instrument() 注册成功不代表具备这些能力,详见External 任务派发

3. 创建履约 Team

DESIGN → Agents 确认五个应用的 External Binding、在线实例与任务能力,再到 DESIGN → Teams 选择 fulfillment-lead 为 Leader,添加另外四个成员。 团队 Instructions:
在控制台新建 Issue,输入样例订单 O-1001,请求在 2026-09-15 到货,阶段为 diagnose。说明中要求使用固定数据,并禁止把演示日期当作今天。

4. 验证一次异常调查

本例正确的调查结果应包含:
  • 订单 O-1001awaiting_stock,原仓 W-A 可用库存为 0。
  • W-B 有 8 件,但查询库存不代表已预留或已完成换仓。
  • 尚无运单;候选最早到货为 2026-09-16,且不保证该日期。
  • 客户要求的 2026-09-15 无法根据现有证据承诺,换仓需要审批。
  • 输出方案与待确认事项;诊断运行结束后没有产生业务变更。
固定数据中的 O-1002 已发货,团队应检查运输进度;O-1003 已取消,不能沿用换仓方案。再测试未知订单、数据不一致和业务接口不可用,检查是否说明原因或转人工。

5. 发布给在线业务调用

在 Team 的 Connections 发布 Job Endpoint,slug 为 order-triage。设置输入 schema 接受以下业务字段;phase 在此诊断入口应限制为 diagnose,不要允许调用方自行切换到执行阶段。
设置 BASE_URL 为 Gateway origin,ENDPOINT_TOKEN 为该 Endpoint 的 key,业务后台发起:
保存 invocationIdeventsUrlstatusUrl,按SSE 指南展示调查进度,结束后读取 invocation.result。该字段中的业务结构由输出契约约定;不要把每一条模型回复直接当作最终客户答复。Endpoint key 放在业务后端,由业务系统补充并校验客户授权上下文。

6. 审批后执行并核对结果

完整闭环可用 Workflow 连接 诊断 Team → approval → 执行 Team。两个 Team 节点可以使用同一团队,但输入阶段和工具授权不同:
  1. 诊断输出具体方案,包括订单版本、拟执行动作及依据;先约定结构化输出,再在设计器映射实际字段。
  2. approval 展示该方案,指定审批人。拒绝时结束本次处置并保留原因,不执行变更。
  3. 执行阶段读取批准记录并重新查询业务状态。订单版本或关键条件改变时返回重新诊断,不能执行过期方案。
  4. 用稳定业务幂等键创建处理单,查询真实处理状态,再汇总结果。创建成功但执行失败时明确部分完成。
Workflow 指南校验并发布具体 revision,再单独发布完整流程 Endpoint。Endpoint Job 的自动完成不等于业务审批,SSE 断线也不应导致新的业务写入。

验收与接入真实系统

对接真实系统时保留这些工具契约和验收条件,更换数据源、认证及业务校验。结束演练后禁用练习 Endpoint,处理未完成运行并清理模拟业务记录。样例数据和 SDK 接入片段不构成已完成真实企业系统联调的证明。