公司级智能体治理与落地方法补充调研

补充目的：本文承接《公司级智能体发展趋势与永辉建设参考调研报告》，不重复外部玩家格局，重点回答“具体补什么信息”“工具注册和权限边界怎么做”“业务对象语义层、可调用工具目录、评估用例集怎么落地”。本文用于方案规划和试点设计，不作为最终建设定案。

1. 结论摘要

• 本文不替代原报告。原报告负责外部趋势和案例认知，本文负责把落地方法拆成对象、工具、权限、评估和试点路线。
• 永辉当前不宜先建“大而全平台”。更稳的路径是先选一个高频、跨系统、风险可控的建议型场景，验证工具、权限、证据和人工确认能否闭环。
• 第一阶段工具目录应以只读查询、建议生成和工单创建为主，不让 Agent 直接改库存、订单、财务或履约结果。
• 业务对象语义层先做最小集合，优先覆盖商品、门店、仓、库存、采购单、配送任务、异常单和供应商。
• 评估工作当前只需要“评估样例池”，用于方案评审和试点设计；进入 POC 后，再把高价值样例扩展成完整测试用例。
• 后续能否平台化，取决于试点是否沉淀出稳定的对象字典、工具目录、权限矩阵、评估样例和复盘机制。

2. 与原报告的关系

原报告适合承担“外部趋势与案例认知”角色，本文建议作为它的补充引用，承担“落地方法与试点拆解”角色。

建议只在原报告执行摘要或结尾增加一段引用说明，正文主体不重写。后续如果进入 POC，可再新建《公司级智能体试点方案》或《智能体工具治理规范》。

3. 总体落地闭环

flowchart TD
    A[选择候选场景] --> B[梳理业务对象]
    B --> C[建设可调用工具目录]
    C --> D[定义权限和风险等级]
    D --> E[建立评估样例池]
    E --> F[开发建议型 Agent 原型]
    F --> G[小范围灰度和日志观测]
    G --> H{是否形成稳定闭环?}
    H -->|否| I[收敛场景或补齐对象/工具/权限]
    I --> B
    H -->|是| J[沉淀规范并评估平台化]

这条闭环把“建设平台”的问题拆成可验证步骤。每一步都要有产物：场景说明、对象字典、工具目录、权限矩阵、评估样例、原型、试运行报告。缺少其中任一环节，都不建议扩大到公司级平台。

4. 需要补充的具体信息

上一轮报告已经覆盖了大模型公司、软件云厂商、FDE/咨询公司、零售供应链案例。现在缺的不是更多公司名，而是把外部材料转成永辉可验证的问题。

这些信息不需要都写进原报告正文。更适合沉淀为“建设问题清单”，用于后续 POC 评审。

5. 业界怎么做工具注册和权限边界

从 ServiceNow、AWS、OpenAI、Google 等公开材料看，企业 Agent 落地通常不会让 Agent 直接面对底层系统，而是在中间加“工具网关 + 身份权限 + 观测评估 + 目录治理”。

5.1 工具注册

工具注册不是把接口 URL 列出来，而是把接口封装成业务能力，并补齐元数据。

永辉第一阶段不应追求工具数量，而应追求工具语义稳定。一个稳定的“查询门店可用库存”工具，比暴露多个库存表查询接口更有价值。

5.2 权限边界

Agent 权限要遵循“用户授权 + 场景授权 + 工具风险分级”三层控制。

建议把工具分成四级：

5.3 场景 Agent

业界不是先建一个“全能 Agent”，而是按角色和流程切小场景。Walmart 按客户、员工、伙伴、开发者划分 super agents；Amazon Project Eluna 面向履约中心运营者；Tesco 从员工助手试点切入。

永辉可以按下面方式拆：

6. 业务对象语义层怎么做

业务对象语义层的目标不是先做大知识图谱，而是让 Agent 能稳定理解“业务对象、字段口径、对象关系、允许动作”。

6.1 第一批对象

建议从物流和门店高频对象开始，不超过 10 个。

6.2 语义层最小交付物

每个对象至少要交付三类文档或配置。

示例：

对象：库存
核心口径：
- 账面库存：系统记录的库存数量，不代表可直接售卖。
- 可用库存：账面库存扣除锁定、质检、异常、预占后的可用数量。
- 在途库存：已发出但未完成收货确认的数量。
允许动作：
- L1：查询门店/仓库存。
- L2：解释库存差异并给处理建议。
- L3：创建库存核查工单。
- L4：调整库存，必须人工审批，试点阶段禁止 Agent 自动执行。

7. 可调用工具目录怎么做

第一阶段工具目录应围绕“只读查询 + 建议生成 + 工单创建”建设，避免直接修改核心业务数据。

工具目录必须有“准入门槛”：

• 没有 owner 的工具不上线。
• 没有字段口径的工具不上线。
• 没有权限规则的工具不上线。
• 没有日志和 traceId 的工具不上线。
• 没有评估用例的工具不上线。

8. 评估样例池怎么做

当前阶段不需要完整测试用例。先建立“评估样例池”，用于方案评审和试点设计。等进入 POC 后，再把高价值样例扩展成 QA 测试用例。样例池必须覆盖真实任务、权限边界和高风险拒绝。

8.1 样例结构

8.2 首批评估样例

8.3 评估指标

9. 三个月试点路线

第 1 阶段：两周内完成场景和对象收敛

目标不是做系统，而是选出一个可控试点。

建议优先试点：仓配异常助手或库存可得性助手。它们业务价值明确，又可以先停留在查询、解释、建议和工单创建，不直接修改核心数据。

第 2 阶段：四到六周完成最小闭环

这一阶段的验收标准不是“能聊天”，而是“能用证据回答真实问题，并且不越权、不瞎改、不绕审批”。

第 3 阶段：四周试运行和复盘

10. 组织和责任分工

公司级智能体不能只靠 AI 工程师，需要一个小型 FDE 式小队。

最小团队可以 5-7 人兼职启动，但必须有明确 owner。没有业务 owner 的 Agent 不建议启动。

11. 决策建议

1. 不建议马上建设“大平台”。先做一个可验证的场景闭环，证明对象、工具、权限、评估和运营可以跑通。
2. 不建议把全部接口转成 MCP 或工具。先选 5-8 个业务语义清晰的只读/建议型工具。
3. 不建议让 Agent 直接改库存、订单、财务、履约。第一阶段必须人工确认。
4. 建议优先补齐四类资产：业务对象字典、工具目录、权限矩阵、评估用例集。
5. 建议把试点结果反向沉淀成永辉自己的智能体建设规范，再决定是否平台化。

12. 下一步可执行清单

本补充文档的核心结论是：永辉现在需要的不是更多“智能体概念”，而是把一个真实流程拆成对象、工具、权限、评估和运营闭环。只要这个闭环能跑通，后续才有必要扩大到 Agent 目录、工具网关和公司级治理平台。