企业 Agent 建设全景：从业务问题到持续运营

本文提出 Digitrhyme 的建设框架建议，需结合具体项目验证。补货场景为教学示例，不代表客户交付或实际经营结果。

第一步：定义业务价值和试点边界

“建设企业智能体”还不足以启动一个项目。把它改写成可观察的工作，例如“帮助采购人员识别缺货风险，准备补货建议”，才能进一步讨论数据、动作和验收。

写出当前的工作方式、频率、处理时间和常见错误，指定一位能判断结果的业务负责人。同时明确第一版不做什么，例如只准备建议、不直接下采购订单。先使用AI 场景评分表记录证据与缺口，再确定试点。

第二步：把业务对象和规则说清楚

本文把业务本体理解为对业务对象、关系、状态和规则的明确描述。它帮助团队对“系统正在谈论什么、允许改变什么”形成共同理解。它不必从一个庞大的全企业模型开始。

Palantir 的 Ontology 文档展示了将平台数据资产关联到真实业务对象的产品实现。可以参考这个思路，但通用业务建模并不要求购买某一产品。查看产品实现参考 ↗

从一个流程里必要的对象开始，为每个字段记录来源、含义、更新频率和责任人。对象的标识必须能与实际系统对应；“可用库存”是否扣除了预留数量，需要在建模时说清，不能交给模型临时猜测。

知识库可提供业务说明，检索可找到相关文档；对象与状态模型帮助识别当前事实，工具接口负责执行动作。它们解决不同问题。简单的只读问答场景可以从文档检索开始，不需要提前建设复杂本体。

第三步：定义智能体可以采取的行动

把“能调用工具”拆成具体约定：输入是什么、读写哪个系统、使用谁的权限、失败如何重试、是否会产生重复动作、怎样保留记录。动作越难撤回，越应明确人工批准与停止条件。

• 读取库存：限制访问范围，并返回数据更新时间。
• 生成建议：输出引用的数据、建议理由和无法判断的条件。
• 提交采购：第一版保留人工批准，避免建议直接变为订单。
• 异常处理：数据冲突或接口失败时暂停动作，交给明确的负责人。

固定流程优先用明确的工作流表达。只有当任务确实需要动态选择步骤时，再引入更自主的 Agent；多 Agent 则需要额外说明分工、共享状态和冲突处理。

第四步：上线前建立评估样本

从真实任务类型构建经过适当处理的评估材料，覆盖正常情况、缺失数据、相互矛盾的数据和越权请求。每个样本写清期望结果，允许“暂停并询问”成为正确答案。

第五步：明确如何进入真实流程

先让系统在有限范围内运行，例如只覆盖一个团队或一种任务。根据风险选择仅观察、提供建议、批准后执行等模式。把异常处理和恢复方式写入上线准备材料，并演练关键失败路径。

第六步：用运行证据持续改进

运行后观察任务成功、人工接管、错误类型和成本变化。对每次重要变更保留模型、规则、知识及工具版本信息，并用既有评估材料检查变化的影响。

补货示例中，如果建议频繁被拒绝，先分类原因：数据过期、规则缺失、业务例外，还是表达不清。不同原因对应不同改进，不应统一归结为“换一个更强模型”。

这六步可以在小范围内循环推进。每轮只扩大经过验证的部分，逐步沉淀企业自己的业务语义、评估材料和运行能力。需要外部团队协作时，可以继续阅读FDE 协作方式指南，先划定双方责任再讨论实施。