不少企业的AI建设已经进入“应用越来越多”的阶段。
制度问答、材料生成、会议纪要、表格分析等智能体陆续上线，单独测试时效果都不错。真正推广后却发现，员工依然习惯找同事处理任务。
问题通常不是模型能力不足，而是企业缺少统一的能力目录和任务路由。
下面以“生成课程月度运营复盘”为例，拆解AI工作助理如何把多个孤立智能体组织成一条可运行、可评估的任务链路。
案例根据常见交付场景整理，不对应具体客户，也不使用虚构业务数据。
一、原始方案：一个聊天框加几个独立智能体
某培训服务机构已上线四类AI应用：
- 课程制度问答；
- 会议纪要整理；
- 表格分析；
- 运营材料生成。
运营人员提出任务：
帮我做一份7月课程运营复盘，分析报名、到课、用户反馈和下月改进方向。
通用AI助手很快生成了一份结构完整的报告。但检查后发现，报告没有读取7月报名数据，也没有分析用户反馈，其中不少结论来自模型的一般性推断。
从接口返回状态看，这次调用成功了；从业务结果看，任务没有完成。
一个真实的运营复盘至少包含：
- 查询报告模板和指标口径；
- 获取报名、到课和历史对比数据；
- 汇总用户反馈；
- 完成数据清洗和统计；
- 生成带依据的报告；
- 检查结论和敏感信息；
- 由运营负责人确认。
因此，问题不能继续靠修改提示词解决，需要把任务拆成可调用的能力。
二、建立能力目录，而不是继续增加入口
团队首先为现有AI能力建立统一目录。
每项能力不只记录名称，还要说明适用场景、输入输出、权限、负责人和更新时间。
{ "id": "course_table_analysis", "name": "课程数据分析Skill", "scenarios": [ "报名统计", "到课分析", "月份对比", "异常值提示" ], "inputTypes": ["xlsx", "csv"], "outputType": "structured_metrics", "allowedRoles": ["operation"], "riskLevel": "low", "owner": "data-operation", "version": "1.0" }
能力目录中可以登记四类对象：
- 知识库：制度、课程资料、指标口径和报告模板；
- Skills：表格清洗、统计分析、报告生成和格式检查；
- MCP Server：连接报名系统、CRM和文件服务；
- 专业智能体：材料写作、数据分析和客户服务应用。
AI工作助理基于员工角色检索目录，只推荐其有权使用的能力。
这一步解决的是“组织里到底有哪些AI能力”，而不是“模型还能增加什么功能”。
三、把任务拆成Planner、Generator、Evaluator
改造后的AI工作助理采用P/G/E结构。
1. Planner：生成执行计划
Planner识别用户角色、任务目标、所需数据和风险边界。
针对课程复盘任务，输出计划：
task: monthly_course_review steps: - load_metric_definition - query_enrollment_data - query_attendance_data - analyze_feedback - calculate_metrics - generate_report - evaluate_report required_role: operation write_operation: false human_confirmation: true
Planner不直接生成最终报告，而是确定应该调用哪些能力，以及什么情况下必须停止。
2. Generator：调用知识和工具
Generator根据计划调用：
- 运营指标控制知识库；
- 课程资料证据知识库；
- 报名系统只读MCP；
- 表格分析Skill；
- 运营报告生成Skill。
报名系统MCP只开放查询，不开放修改订单、调整班次等写操作。
示例工具描述：
{ "tool": "query_course_metrics", "permission": "read_only", "required": ["course_id", "start_date", "end_date"], "returns": [ "registrations", "attendance", "refunds" ], "onFailure": "stop_and_request_manual_data" }
如果系统查询失败，流程立即停止并提示补充数据，不能让模型估算报名人数后继续生成报告。
3. Evaluator：检查结果是否可用
Evaluator根据Planner设定的标准检查：
- 报名与到课数据是否来自指定时间范围；
- 指标口径是否一致；
- 结论是否有数据或反馈依据；
- 是否遗漏异常值说明；
- 是否包含个人敏感信息；
- 建议是否被误写成确定决策；
- 报告格式是否符合模板。
不通过的结果返回Generator修改。最终版本进入人工确认，而不是直接发布。
上下文记忆只保留经过确认的报告偏好、历史纠错和有效模板，不自动修改知识库或MCP配置。
四、知识库要分成“规则”和“证据”
原方案把报告模板、课程资料、运营规则和历史复盘全部放在同一个知识库里，容易出现新旧口径冲突。
改造后拆成两层。
控制知识库存放：
- 指标定义；
- 报告结构；
- 输出边界；
- 禁止推断的内容；
- 需要转人工的条件。
证据知识库存放：
- 课程资料；
- 运营数据说明；
- 历史复盘；
- 用户反馈和业务材料。
执行时先读取控制知识库，确定口径，再检索证据知识库补充事实。
如果证据不足，系统输出“当前资料不足以支持该结论”，而不是用通用知识补齐。
五、失败路径必须在上线前设计
智能体项目容易重点设计“成功时怎么运行”，却忽略失败状态。
课程复盘任务至少要覆盖以下异常：
- 用户没有运营数据权限；
- 报名系统连接失败；
- 表格缺少必填字段；
- 指标口径发生冲突；
- 用户反馈样本不足；
- 报告出现未经数据支持的判断；
- 用户要求系统自动修改课程安排。
对于这些情况，需要明确采用拒绝、降级、补充资料或转人工，而不是统一交给模型自由处理。
例如：
数据权限不足 -> 拒绝查询并说明所需权限 MCP调用失败 -> 停止报告生成 字段缺失 -> 返回缺失字段清单 资料冲突 -> 使用控制知识库口径并提示人工确认 高风险写操作 -> 禁止自动执行
六、验收指标要从“生成成功”转向“任务完成”
只统计调用次数和回答数量，很难判断AI工作助理是否有效。
建议从四层验收。
任务路由：
- 是否识别为运营复盘任务；
- 是否调用正确能力；
- 是否避免推荐无权限应用。
数据处理：
- 数据是否完整；
- 时间范围和指标口径是否正确；
- 工具调用失败后是否停止。
内容质量：
- 结论是否有依据；
- 是否遗漏必要章节；
- 人工需要修改哪些内容。
业务效果：
- 运营人员是否完成复盘；
- 哪些步骤仍需人工重复处理；
- 用户是否反复询问；
- 新的能力缺口集中在哪里。
“生成了一份报告”是系统输出，“帮助运营人员完成复盘”才是业务结果。
七、AI工作助理的一期边界
一期产品不建议做成拥有所有系统权限的超级智能体。
更稳妥的范围是：
- 处理低风险轻办公；
- 查询组织AI能力目录；
- 推荐或路由到专业应用；
- 调用只读型MCP；
- 生成待确认结果；
- 记录未满足需求。
当用户提出“分析投诉并判断哪些顾问存在问题”时，系统应记录需要投诉知识库、问题分类Skill、CRM只读MCP和人工复核规则，而不是直接生成员工评价结论。
这种需求记录就是“需求雷达”，可以帮助平台管理者决定下一步建设什么能力。
八、两种部署形态不要混淆
B端智能体创作者、AI服务商和垂类服务团队使用的智能体运营平台，要适合组织智能体入口、客户服务、知识能力和持续运营。
高校、政府、医院、国企和产业园区等机构，则更适合私有化AI服务要素平台，重点解决数据不出域、模型中立、权限审计、系统集成和长期演进。
两者都围绕模型、智能体和数据与能力集合展开，但客户对象、部署方式和治理深度不同。
不过企业AI工作助理的真正价值，不是把所有能力塞进一个聊天框，而是完成三件事：
- 让员工知道组织里有什么AI能力；
- 把任务路由给正确的知识、Skill、MCP或专业智能体；
- 将失败和未满足需求沉淀为下一轮建设依据。
当一个任务能够被拆解、调用、评估、人工确认并持续改进时，智能体才真正从Demo进入业务。
