Selected product work / Anonymized case study
把 Agent、工具与业务能力组织成可治理的系统
用“业务任务—场景 Agent—领域工具—触发方式—治理策略”组织能力，避免 Agent 数量膨胀与工具权限失控。
- Status
- Product design · Validated prototype
- Scope
- Agent architecture · Tool governance
- Topics
- AI Agents · MCP · Platform design
An anonymized case study based on enterprise product design work. Client, company, implementation and commercial details are intentionally omitted.
背景
当多个产品域同时接入 AI，最容易出现的不是能力不足，而是命名、入口、工具和权限各自生长：一个功能一个 Agent、一个页面一个助手、每个团队维护一套调用方式。
用户看到的是不断增加的 Agent 名称，平台承担的却是重复工具、重叠职责、不可见权限与难以追踪的调用关系。
需要解决的问题
如果按页面或功能创建 Agent，数量会随产品菜单线性增长，却不能回答“用户究竟要完成什么工作”。
如果把所有 API 包装成一个通用工具箱，Agent 可以调用什么、何时能写、失败由谁处理都会变得模糊。
本案例呈现的工作
- 从用户要完成的业务任务反推 Agent 边界，而不是从已有页面或模型能力出发。
- 将用户可见的场景 Agent 与可复用的领域工具分层，建立统一的触发、授权与审计关系。
- 用能力目录和交互原型检查重复能力、越权写操作与跨产品依赖。
约束
- 同一领域能力需要被多个场景复用，不能复制成互不兼容的 Agent。
- 读取、建议与写入必须分开授权，工具描述不能等同于调用许可。
- 工程术语需要留在平台治理层，业务用户只应看到任务、条件与结果。
- 跨产品调用需要统一身份、上下文、错误语义与追踪记录。
关键产品决策
- Agent 以业务任务命名
- Agent 对应一个有开始、判断与完成条件的工作，而不是一个页面、按钮或模型能力。
- 工具按领域沉淀并复用
- 监控、配置、工单与自动化能力作为受治理工具存在，同一工具可以服务多个场景 Agent。
- 触发方式是一等设计对象
- 用户发起、事件触发、定时触发与工作流调用拥有不同的上下文、响应时间和责任边界。
- 策略决定可调用范围
- 工具是否可见、是否可写、作用对象、调用次数与审批要求由策略控制，并进入统一审计。
系统模型
Business job
以用户需要完成的工作定义入口与成功条件。
Scenario agent
管理任务上下文、推理过程与多步协作。
Domain tool
提供边界清晰、可复用、可观测的读取或动作能力。
Trigger
声明由人、事件、计划或工作流何时启动。
Policy
校验身份、权限、对象范围、风险和审批要求。
Trace
记录输入、工具调用、状态变化、结果与人工反馈。
明确舍弃的方案
- 一个功能对应一个 Agent
- 它复制现有菜单结构，制造命名膨胀，却没有形成新的任务能力。
- 所有能力放进通用工具箱
- 工具边界、权限与异常责任无法按业务风险治理。
- 把 MCP 等工程概念直接暴露给业务用户
- 用户需要理解任务与后果，而不是学习平台内部的连接协议。
- 绕过目录的私有调用
- 无法统一发现、授权、版本管理和审计的能力会成为长期治理盲点。
证据类型
原始材料位于非公开产品仓库。这里列出用于形成判断的产物类型，不提供内部文件、截图或链接。
- Capability map
- 业务任务、Agent、工具、触发与策略之间的映射。
- Agent and tool catalog
- 能力边界、输入输出、权限与复用关系。
- Governance rules
- 身份、授权、写操作、配额、审计与版本要求。
- Platform prototype
- 面向业务用户和平台管理员的双层交互原型。
当前公开状态
已完成能力架构、目录模型与关键治理交互的产品设计验证。
公开版本不披露内部能力清单、接口数量、实现计划与组织分工。
An anonymized case study based on enterprise product design work. Client, company, implementation and commercial details are intentionally omitted.