先说结论：AI Agent 不是“更聪明的聊天机器人”，而是一段能自己决定调什么工具、分几步把事做完的程序。它适合的任务有三个共同点——流程相对固定、需要读非结构化资料、需要调用多个系统；同时要留出人工复核的口子。反过来，凡是要求 100% 准确、或者一天几万次的高频确定性业务，用规则代码或普通接口比 Agent 便宜也稳。
判断一个业务该不该做成 Agent，只看三个问题
- 频率：一天几十到几百次最合适。太少不值得开发，太多不如写死流程。
- 容错：错了能不能被人一眼看出来、能不能撤回。能复核的才适合交给模型判断。
- 可调用性：背后有没有接口（ERP、CRM、工单、数据库）。系统调不通，Agent 只能“嘴上说说”，落不了地。
| 业务场景 | 是否适合 | 原因 |
|---|---|---|
| 客服工单分类 + 首轮回复草稿 | 适合 | 文本为主、有人工复核、错了可改 |
| 招投标文件关键条款抽取比对 | 适合 | 读长文档、规则明确、结果可核验 |
| 跨系统数据核对（订单/库存/财务） | 适合 | 多系统调用、步骤固定、异常值可标注 |
| 每日固定格式报表生成 | 一般不适合 | 用定时脚本更快更准，模型只会增加不确定性 |
| 实时支付风控决策 | 不建议 | 零容错、要求毫秒级与可解释性 |
两类最常见的伪需求
第一类：把“会聊天”当成“会干活”。很多需求写的是“做一个 AI 助手”，实际拆开看，80% 的价值在接口打通和数据治理上，模型只占很小一块。这类项目如果按 Agent 报价，最后一定扯皮——因为工作量根本不在模型。
第二类：流程本身还没理顺。线下审批靠人传话、字段口径三套并存的时候上 Agent，等于让模型学一套混乱的规则。我们的经验是：先花两周把流程和字段定义清楚，比急着接大模型有用得多。
一个能上线的 Agent 最小闭环长什么样
| 模块 | 作用 | 常见做法 |
|---|---|---|
| 工具层 | 让模型能查、能写、能算 | MCP / OpenAPI 封装成函数，权限按最小化给 |
| 知识层 | 提供企业内部事实 | RAG 检索，返回带出处的片段 |
| 编排层 | 决定先做什么后做什么 | 状态机 + 有限工具集，避免自由发挥 |
| 评测层 | 上线前后量效果 | 固定 100–300 条真实任务做回归集 |
| 兜底层 | 错了怎么办 | 低置信度转人工、关键写操作二次确认 |
最容易忽略的是评测层。没有回归集，Agent 每次改 Prompt 都是“感觉好像好一点”，上线后问题只会以碎片形式暴露给客服。
周期和预算大概是什么量级
单场景、单系统的 Agent（比如工单分类 + 回复草稿），从需求梳理到上线通常 4–8 周；涉及 3 个以上系统打通、需要权限体系与审计日志的，一般 2–3 个月。预算区间常见在 6–10 万元，其中接口与权限改造往往占一半以上。
如果只是验证“能不能做到”，先做 2–4 周的 POC：拿 50 条真实任务跑一遍，看准确率和人工修正成本，再决定要不要继续。这比直接立项省得多。
