AI 员工

客户说要做 Agent，别急干，先问清楚这 4 个问题

2026 年 9 月 3 日

本文指出企业提出“要做 Agent”仅是需求起点，而非开工信号。需前置判断四个关键问题：业务价值是否明确可衡量；基础与知识数据是否具备、准确、可用；所需业务能力（如系统接口、权限、执行能力）能否真正接入；当前场景是否真正需要 Agent，还是规则引擎或工作流更合适。

不是 Agent 不会做，而是业务还不具备条件

以前做 Agent 项目，客户说一句：“我们想做一个 Agent。”我的第一反应是：怎么设计？现在不一样了。我会先问一句：这个业务，真的适合做 Agent 吗？

我之前就遇到过一个项目。客户想做一个智能运维 Agent，帮运维人员快速定位问题、辅助故障处理，把整体效率提上去。听起来目标很明确，方向也清楚。于是我们开始梳理需求、设计方案，客户对方案反馈也不错。

但真正准备建设的时候，问题来了：基础数据不够准确，运维知识和历史案例没有沉淀，部分业务需要调用周边系统，但系统又没有开放接口。这时候才发现：不是 Agent 不会做，而是这个业务本身还不具备做好 Agent 的条件。

第一关，我会先问：这个 Agent 做出来，到底解决什么问题？不能光说“提升效率”“降低成本”——提谁的效？降谁的成本？

如果一个场景实际用的人没几个、一天也没几单，Agent 就算做出来了，价值也有限，投入产出不划算。所以第一关不是判断“能不能做”，而是先判断：有没有明确的业务价值，而且这个价值能不能被衡量。

第二关看数据。这里我一般会分成两类。

第一类是基础业务数据：比如客户、设备、网络、订单、工单、资源等数据。要看三个东西：有没有、准不准、能不能用。有些企业系统里看着数据挺多，其实是靠人工维护的，缺的缺、错的错。这种数据要是直接喂给 Agent，结果自然好不了。
第二类是知识和经验数据：比如历史故障案例、处理经验、业务规则、操作规范、专家知识等。很多企业不是没有经验，而是经验都在老员工脑子里，没沉淀下来。

这也是我之前那个智能运维项目遇到的问题：基础数据不够可靠，历史运维知识又没有真正沉淀。所以数据这一关，不只是问：“你们有没有数据？”而是要判断：基础数据够不够、准不准，知识经验有没有沉淀，Agent 真正需要的数据能不能拿来用。

有了数据，还不代表 Agent 就能干活。第三关要看：Agent 需要的业务能力，能不能打通接入。

比如 Agent 要分析一个故障，可能需要查询客户、设备、网络、工单等多个系统。那就要看：数据在哪里？有没有接口？有没有权限？能不能提供给 Agent？

如果 Agent 不只是分析，还得执行操作——创建工单、修改配置、发起任务，那就得继续看：有没有接口？接口开不开放？权限允不允许？哪些操作必须人工确认？

之前那个项目就是卡在这：客户希望 Agent 能查、能操作，但周边系统没开放对应接口。这时候你会发现：Agent 的能力边界，不是由 Prompt 决定的。底层系统能提供什么，Agent 才真正能做什么。

当然，不是所有 Agent 都需要调用工具。但只要涉及外部数据获取、系统查询或者业务执行，这一关就必须提前判断。

前三关都没问题，还要问最后一个问题：这个业务真的需要 Agent 吗？

有些业务看起来可以用 AI，但实际上用规则、工作流或者传统系统解决，可能更稳定。比如一个业务：输入固定、规则明确、流程标准、输出确定。那直接用规则引擎或者工作流自动化，可能比 Agent 更合适。

Agent 更适合的是：用户表达不固定，要理解自然语言；要结合好几处信息来判断；处理过程不能全写死，得随机应变。

所以不能因为现在大家都在做 Agent，就什么业务都往 Agent 上套。能用 Agent，不代表应该用 Agent。真正需要判断的是：这个业务的问题，是不是 Agent 最适合解决的问题。

所以现在再有人跟我说：“我们想做一个 Agent。”我不会马上开始画流程、设计 Agent。我会先把四件事问清楚：

其实就是四个问题：值不值得做？有没有基础做？能不能真正落地？是不是非 Agent 不可？

这四个问题都回答清楚了，再去考虑模型怎么选、Prompt 怎么写、要不要 RAG、需不需要微调、需要哪些 Tool。因为我现在越来越觉得：Agent 项目真正难的，很多时候不是“怎么把 Agent 做出来”，而是前面根本没判断清楚——这个业务到底适不适合做 Agent。

客户说“我们想做 Agent”，只是一个需求起点。不是 Agent 项目可以直接开工的信号。

对企业部署意味着：在立项阶段即需将 Agent 视为系统级集成产物，而非孤立模型应用。其可行性高度依赖现有IT资产的开放性与数据治理成熟度，未完成系统接口解耦或主数据标准化的企业，应优先补足基础设施，而非直接启动Agent开发。
这类系统的取舍在于：当业务流程高度结构化且规则明确时，引入Agent反而增加不确定性与维护成本。企业需建立评估矩阵，将‘输入模糊性’‘决策依据分散性’‘执行路径动态性’作为是否采用Agent的核心判据，避免技术驱动替代问题驱动。
对RAG知识工程提出前置要求：知识未沉淀=RAG无源可溯。运维类Agent依赖的历史案例、排障手册等非结构化知识，若仍以个人笔记、会议纪要、口头传承形式存在，须先完成知识萃取与结构化建模，否则RAG仅能返回低置信度片段，无法支撑可靠推理。
AI安全治理需覆盖Agent的能力边界校验环节：当Agent需调用生产系统接口时，权限控制、操作留痕、人工复核点等机制必须在设计初期嵌入，而非后期追加。缺乏API治理规范的企业，应将接口白名单与操作审计能力列为Agent上线的强制准入条件。