以前做 Agent 项目，客户说一句：
“我们想做一个 Agent。”
我的第一反应是：
怎么设计？
现在不一样了。
我会先问一句：
这个业务，真的适合做 Agent 吗？
我之前就遇到过一个项目。
客户想做一个智能运维 Agent，帮运维人员快速定位问题、辅助故障处理，把整体效率提上去。
听起来目标很明确，方向也清楚。
于是我们开始梳理需求、设计方案，客户对方案反馈也不错。
但真正准备建设的时候，问题来了：
基础数据不够准确，运维知识和历史案例没有沉淀，部分业务需要调用周边系统，但系统又没有开放接口。
这时候才发现：
不是 Agent 不会做，而是这个业务本身还不具备做好 Agent 的条件。
所以后来再做 Agent 项目，客户一说"要做 Agent"，我不会马上开工，而是会先判断四件事。
01 先看值不值得做：业务价值是否明确
第一关，我会先问：
这个 Agent 做出来，到底解决什么问题？
不能光说"提升效率"“降低成本”——提谁的效？降谁的成本？
比如：
有多少人会用？
每天有多少业务量？
现在处理一件事情需要多久？
希望 Agent 上线后改善什么？
上线前后的效果怎么衡量？
如果一个场景实际用的人没几个、一天也没几单，Agent 就算做出来了，价值也有限，投入产出不划算。
所以第一关不是判断"能不能做"，而是先判断：
有没有明确的业务价值，而且这个价值能不能被衡量。
02 再看有没有条件做：数据基础是否具备
第二关看数据。
这里我一般会分成两类。
比如客户、设备、网络、订单、工单、资源等数据。
要看三个东西：
有没有、准不准、能不能用。
有些企业系统里看着数据挺多，其实是靠人工维护的，缺的缺、错的错。
这种数据要是直接喂给 Agent，结果自然好不了。
这类数据其实同样重要。
比如历史故障案例、处理经验、业务规则、操作规范、专家知识等。
很多企业不是没有经验，而是经验都在老员工脑子里，没沉淀下来。
这也是我之前那个智能运维项目遇到的问题：
基础数据不够可靠，历史运维知识又没有真正沉淀。
所以数据这一关，不只是问：
“你们有没有数据？”
而是要判断：
基础数据够不够、准不准，知识经验有没有沉淀，Agent 真正需要的数据能不能拿来用。
03 还要看能不能真正落地：业务能力是否具备
有了数据，还不代表 Agent 就能干活。
第三关要看：
Agent 需要的业务能力，能不能打通接入。
比如 Agent 要分析一个故障，可能需要查询客户、设备、网络、工单等多个系统。
那就要看：
数据在哪里？有没有接口？有没有权限？能不能提供给 Agent？
如果 Agent 不只是分析，还得执行操作——创建工单、修改配置、发起任务，那就得继续看：
有没有接口？接口开不开放？权限允不允许？哪些操作必须人工确认？
之前那个项目就是卡在这：
客户希望 Agent 能查、能操作，但周边系统没开放对应接口。
这时候你会发现：
Agent 的能力边界，不是由 Prompt 决定的。
底层系统能提供什么，Agent 才真正能做什么。
当然，不是所有 Agent 都需要调用工具。
但只要涉及外部数据获取、系统查询或者业务执行，这一关就必须提前判断。
04 最后看是不是该用 Agent：场景与 Agent 是否匹配
前三关都没问题，还要问最后一个问题：
这个业务真的需要 Agent 吗？
有些业务看起来可以用 AI，但实际上用规则、工作流或者传统系统解决，可能更稳定。
比如一个业务：
输入固定、规则明确、流程标准、输出确定。
那直接用规则引擎或者工作流自动化，可能比 Agent 更合适。
Agent 更适合的是：
用户表达不固定，要理解自然语言；要结合好几处信息来判断；处理过程不能全写死，得随机应变。
所以不能因为现在大家都在做 Agent，就什么业务都往 Agent 上套。
能用 Agent，不代表应该用 Agent。
真正需要判断的是：
这个业务的问题，是不是 Agent 最适合解决的问题。
所以现在再有人跟我说：
“我们想做一个 Agent。”
我不会马上开始画流程、设计 Agent。
我会先把四件事问清楚：
① 业务价值是否明确
② 数据基础是否具备
③ 业务能力是否可获得
④ 场景与 Agent 是否匹配
其实就是四个问题：
值不值得做？
有没有基础做？
能不能真正落地？
是不是非 Agent 不可？
这四个问题都回答清楚了，再去考虑模型怎么选、Prompt 怎么写、要不要 RAG、需不需要微调、需要哪些 Tool。
因为我现在越来越觉得：
Agent 项目真正难的，很多时候不是"怎么把 Agent 做出来"，而是前面根本没判断清楚——这个业务到底适不适合做 Agent。
客户说"我们想做 Agent"，只是一个需求起点。
不是 Agent 项目可以直接开工的信号。
粤ICP备14082021号
免费POC，
零成本试错
