AI Agent企业落地手册：场景、ROI与治理

客服主管老周想把工单自动分类，技术团队建议先做全能助手。我的建议相反：先拉 200 条历史工单，标注意图和期望动作，算一次每任务成本。Agent 企业落地失败，常见原因是场景选错、权限给大、评测只看准确率。

场景筛选：高频、低风险、数据能拿到

先看三个条件：任务每天发生次数、错误后能否人工兜底、数据是否有稳定 API。满足两条再谈试点。

场景	频率	错误成本	数据接口	建议
工单分类	高	低	已有工单系统 API	先做
内部知识问答	高	低	文档库、Confluence	先做
发票信息提取	高	中	OCR + ERP	做，加人工复核
合同审批	低	高	法务系统	后做
付款操作	低	极高	财务系统	不先做

筛选评分表，每项 0-2 分：

频率：每天大于 100 次得 2 分
单次人工耗时：大于 3 分钟得 2 分
错误成本：可人工复核得 2 分
数据接口：有稳定 API 得 2 分
人工复核成本：低于节省得 2 分

总分大于 7 分进入试点。

选一个场景，不要跨三个系统。
抽 200 条真实历史数据做评测集。
跑两周影子模式：Agent 只记录建议，不执行。
统计人工采纳率和接管原因。

工具调用与 MCP：让 Agent 拿到最小权限的接口

工具调用：LLM 输出 JSON，调用你写的函数。OpenAI 在 2023 年 6 月推出 function calling；Anthropic 有 tool use；通义千问、Kimi、智谱等也有类似接口。参考 OpenAI 文档：https://platform.openai.com/docs/guides/function-calling

MCP：Model Context Protocol，Anthropic 在 2024 年 11 月开源。它把工具、资源、提示模板标准化，客户端和服务器解耦。官方文档：https://modelcontextprotocol.io/ 。2026 年，Claude Desktop、Cline、Continue 等客户端支持 MCP；企业可以用 @modelcontextprotocol/sdk 写内部 MCP Server。

维度	直接函数调用	MCP
接入方式	每个模型写一套 schema	一次封装，多客户端复用
权限	写在代码里	可做独立进程和审计
适用	单一模型、快速验证	多工具、多模型、长期维护

flowchart LR U[用户请求] --> A[Agent 规划] A --> T{需要工具?} T -- 否 --> R[直接回答] T -- 是 --> M[MCP Client] M --> S1[MCP Server: 工单查询] M --> S2[MCP Server: 知识库检索] S1 --> A S2 --> A A --> C{写操作?} C -- 是 --> H[人工确认] C -- 否 --> R

接入步骤：

定义工具 schema：工具名、参数、必填项、返回结构。参数用枚举，不要自由文本。
封装 MCP Server：只读接口先上，写操作单独 Server，加审批参数。
客户端配置：Claude Desktop 或 Cline 的 mcp.json 里填 command、args、env。
加固：超时 10 秒，重试 2 次，幂等键用业务 ID，日志记录 request_id。

Python MCP Server 最小示例：

from mcp.server.fastmcp import FastMCP
mcp = FastMCP('ticket-tools')
@mcp.tool()
def get_ticket(ticket_id: str) -> dict:
    # 按工单 ID 查询工单，只读
    return {'ticket_id': ticket_id, 'status': 'open'}
if __name__ == '__main__':
    mcp.run()

生产环境要接内部 API、鉴权和审计。

数据权限：Agent 不能比员工权限大

原则：以用户身份执行。用户能看的，Agent 才能看；用户不能看的，Agent 也不能看。

模式	做法	风险
用户令牌透传	把用户 OAuth token 传给工具	令牌泄露、过期处理
服务账号+行级过滤	服务账号查库，按 user_id 过滤	过滤条件写错会越权
查询代理	所有查询走代理，代理做鉴权	实现复杂，但审计清楚

具体做法：

OAuth 2.0 授权码模式，不要用共享 API Key。
RBAC 和 ABAC 结合：角色控制功能，属性控制数据行。
向量库 metadata 过滤：检索时带 tenant_id、dept_id、user_id。
SQL 行级安全：PostgreSQL RLS 或数仓视图。
审计日志字段：user_id, agent_id, tool_name, input, output, timestamp, request_id。日志至少保存 180 天，具体看行业要求。

上线前检查：

Agent 是否使用了超级管理员账号？
写操作是否有人工确认？
是否记录了每次工具调用？
是否测试了越权查询？用普通员工账号试查其他部门数据。

评测指标：任务成功率比准确率有用

指标	定义	目标示例
任务成功率	无需人工接管完成任务的比例	> 70%
工具调用正确率	参数和工具选择正确的比例	> 90%
平均轮次	完成任务的平均对话轮数	< 5
人工接管率	需要人工介入的比例	< 30%
P95 延迟	95% 请求的响应时间	< 8 秒
每次任务成本	token + 工具 + 复核	低于人工成本 30%
安全违规率	越权、泄露、危险操作	0

评测集：从真实工单抽 100-200 条，人工标注期望工具调用和最终结果。离线跑，比较模型和提示词版本。上线后做 A/B，但不要同时改模型和提示词。

准确率高但人工接管率高，说明工具不可用或权限不够。延迟低但成本高，可能用了大模型处理简单分类。

成本模型：算清每任务成本和回收期

成本组成：

LLM token：输入 + 输出。
工具调用：API 费用、数据库查询。
向量检索：嵌入模型 + 向量库。
基础设施：服务器、网关、日志。
人工复核：按小时算。
维护：提示词更新、评测、故障处理。

公式：

每任务成本 = (输入 token × 输入单价 + 输出 token × 输出单价) + 检索成本 + 工具成本 + 复核成本 + 固定成本分摊

ROI = (节省人工成本 - 总成本) / 总成本

投资回收期 = 总投入 / 每月净节省

示例（假设数字，只用于计算模板）：

客服工单分类，每天 1000 单，人工每单 2 分钟，时薪 60 元。

节省：1000 × (2/60) × 60 = 2000 元/天。

Agent 成本：token 0.02 元/单 × 1000 = 20 元；复核 10% × 1 元/单 = 100 元；基础设施 50 元。总成本 170 元/天。

净节省 1830 元/天。ROI 约 10.7 倍。

这个示例没有算开发人力和维护。加上开发 5 人天、维护 0.5 人天/周，回收期会变长。实际决策要用内部数据。

组织变革：谁负责、谁复核、谁更新

角色	负责
业务负责人	定义成功标准，决定是否上线
AI 工程师	提示词、工具、评测
数据/安全	权限、审计、合规
一线复核员	处理接管、反馈错误
运维	监控、告警、回滚

上线流程：

需求评审：业务负责人签字。
影子模式：Agent 只建议，不执行。2 周。
灰度：10% 流量，人工确认写操作。
正式上线：只读自动，写操作按风险分级。
月度复盘：看指标、成本和接管原因。

版本管理：

提示词版本号：prompt-v1.2.0。
工具版本号：tool-ticket-v1.0。
评测集版本号：eval-ticket-2026-01。
变更日志：谁改了什么，为什么改。
回滚方案：一键切回旧版本或人工流程。

培训一线：教他们写复核意见，比如“工具调用正确，但参数少了 department_id”。这些意见用来补评测集。

下一步

选一个高频低风险场景，拉 200 条历史数据，标注意图和期望工具调用，用上面的公式算一次每任务成本。不要先买 GPU，也不要先做跨系统写操作。

免责声明：文中提到的工具、协议和链接可能更新，以官方文档为准。示例数字只用于计算模板，不构成收益承诺。