智能体输出接不进业务系统，常见原因是结果停留在一段自由文本。业务系统需要可校验、可映射和可追踪的数据：字段有哪些、哪个缺失、什么条件允许写入、失败时由谁处理。先让模型给出结构化结果，再由 Workflow 校验和执行，Agent 的判断才有机会进入业务流程。
ZGI 这类可自托管 Agent Runtime 可以把 Agent、结构化数据、Skills、工具和 Workflow 组织在同一工作区。模型负责理解用户目标和整理信息，Workflow 承接字段检查、条件分支、数据库或 HTTP 调用。这样的拆分让自然语言结果与实际业务动作之间多了一层可验证的接口。
概念示意图：模型结果经过字段校验后，才进入业务系统。
先声明后续系统真正需要的字段
以售后申请为例，后续流程通常需要订单号、问题类型、处理方式、联系方式和附件状态。用户只说“商品有问题，想退”，模型可以理解意图，却不宜直接把一段总结发送给退款接口。
先声明字段，测试标准会变得具体。订单号缺失，流程向用户补问；问题类型超出允许范围，转给人工确认；附件状态不清楚，先暂停写入。模型输出还可以附带原始依据，方便后续人员核对它从哪句话提取了某个值。
| 输出形式 | 适合做什么 | 进入业务系统前还缺什么 |
|---|---|---|
| 自由文本 | 说明、总结、对话回复 | 无法稳定识别字段和处理条件 |
| 结构化字段 | 表单、数据库记录、接口请求 | 仍需检查必填项、类型和权限 |
| 工具返回结果 | 查询状态、写入回执、文件地址 | 需要核对目标对象与实际处理状态 |
结构化输出也不等于一定正确。它只是让错误更容易被发现：缺字段、类型不符、枚举值无效、对象编号不存在，都可以在真正执行前拦下来。
模型判断和业务写入分开处理
“建议退款”“需要补件”属于模型判断。系统准备写入订单、发送通知或更新数据库前，还要确认订单是否存在、当前状态是否允许变更、执行身份拥有哪些权限，以及该动作是否需要审批。
一条更稳的链路可以这样组织：Agent 先输出结构化意图，Workflow 校验字段与条件，工具查询或写入业务系统，再把对象编号、处理状态和回执返回。模型判断、执行请求和最终结果分别保留，出错时更容易找到问题发生在哪一层。
在 ZGI 中，Workflow 可以连接模型调用、条件分支、用户问答、HTTP 请求和数据库操作。重复出现的字段清洗、接口参数转换或文件处理，也可以整理成 Skill，供多个流程复用。业务规则发生变化时，团队只需调整对应环节，避免把所有逻辑继续堆进提示词。
先用反例测试结构是否真的可用
正常样本跑通之后，还要测试缺订单号、同时出现多个编号、用户表达含糊、接口返回空值和重复提交等情况。检查重点包括：字段能否完整提取，异常是否进入正确分支，写入对象是否准确，任务中断后能否保留当前状态。
如果一段输出无法映射到字段、处理条件和后续动作，它更适合停留在对话中。先固定结构，再校验数据和权限，智能体才有稳定接入业务系统的基础。
GitHub：github.com/zgiai/zgi
Gitee：gitee.com/zgiai/zgi
