别一上来就建 Agent：企业 AI 落地，先把流程断点说清楚

詹老师 · AI产品专家 / 流程管理专家

一个流程有 100 个节点，跨 8 个系统，要 20 个人才能跑完。

业务方说，其中 10 个节点可以交给 AI 做。

问题马上来了：到底建 10 个 Agent，还是建 1 个 Agent 从头跑到尾？如果中间是人、AI、人、AI 交替，怎么拆？如果连续两个 AI 节点分别访问不同系统，又该合并还是拆开？

很多企业 AI 项目卡住，不是模型不够强。真正卡住的是这几个问题没人说清楚：Agent 建几个，Skill 建几个，知识库要不要建，提示词还要不要写，最后嵌到哪个系统里。

这篇文章只回答一件事：如何从一个真实业务痛点出发，规划 Agent 和 Skill，并把它落成可验证的流程能力。

图1：先从现状流程里找到人工搬运上下文的位置，再判断哪些活动适合 AI 接手。

一、Agent 不是角色扮演，它是流程里一段可独立交付的责任边界

一个 Agent 不该按组织架构建，而该按流程断点建。

很多人一听 Agent，就容易把它理解成“某个岗位的数字人”。采购 Agent、财务 Agent、法务 Agent，听起来很整齐，但一落到流程里就会乱。

因为真实流程不是按概念走的。它是按节点、系统、权限、等待、确认、退回和异常走的。

如果一个流程是“人 - AI - 人”，AI 做完之后，后面的人要判断、补充材料、改字段、发起审批，那这里就是一个明显断点。前面的 AI 不应该一直挂着等下一个人接话。它应该完成自己的交付，输出结构化结果，然后收尾。

所以，这种场景更适合拆成独立 Agent。一个 Agent 只负责“两个人工节点之间”的那段 AI 工作。

如果流程是“人 - AI - AI - 人”，中间两个 AI 节点没有人工介入，而且第二步要依赖第一步的结果，就可以合并成一个 Agent。它先调 A 系统做提取，再调 B 系统做校验，最后把结果交给下一个人。

但如果这两个 AI 节点只是刚好相邻，业务上没有数据依赖，也不需要同一套判断逻辑，就不要硬合。拆开更清楚，也更容易维护权限。

图2：Agent 拆分先看人工断点、责任边界、上下文和权限，不按系统数量硬拆。

公开资料里的技术定义也能支撑这个判断。OpenAI 的 Agents SDK 把 Agent 看成带有指令、工具、交接、护栏和结构化输出的执行单元；Anthropic 明确区分了 workflow 和 agentic systems；AWS 的多 Agent 协作强调专业 Agent 在各自领域内工作，由上层协调者分配任务。

翻译成业务语言，就是一句话：Agent 的边界不是“像不像一个人”，而是“能不能独立完成一段可交付工作”。

二、Skill 不是万能长提示词，它是 Agent 可以复用的一件小事

一个节点只干一件事，不代表这个节点只能有一个 Skill。

流程节点通常会被描述成一句话：审核合同、校验预算、生成审批意见、整理客户报告。看上去是一件事，但拆开以后，里面可能有多个稳定步骤。

比如一个 AI 节点叫“采购预算预审”。它可能要做三件事。

1从采购单里提取金额、供应商、品类和部门。

2去预算系统校验是否有额度、是否超科目、是否跨期。

3把校验结果写成给审批人的建议。

这时就可以拆成三个 Skill：要素提取 Skill、预算校验 Skill、审批意见生成 Skill。Agent 的职责不是把所有逻辑塞进一个超长提示词，而是按顺序调用这些 Skill。

如果一个步骤会被多个流程复用，就更应该独立成 Skill。合同要素提取，可能用于采购、法务、付款、审计。预算校验，也可能用于报销、采购、立项。

反过来，如果某个节点非常简单，只是按固定格式填一个字段，一个 Skill 就够了。拆得太细，反而会增加编排成本。

图3：采购预算预审 Agent 里，Skill 按读取、校验、比对、摘要这些独立步骤拆。

所以，问“一个 Agent 下应该放几个 Skill”，不要先问数量。要先问三件事。

第一，这个节点内部有没有明确步骤。第二，步骤之间是串行、并行，还是没有依赖。第三，其中某一步以后会不会被别的 Agent 复用。

答案出来以后，Skill 数量自然就出来了。

三、知识库不是每个 Agent 的标配，只有规则会变化时才需要

纯数据搬运不需要知识库，规则、模板、案例才需要知识库。

很多团队做 Agent 时，会下意识给每个 Agent 配一个知识库。看起来更完整，但不一定有用。

如果任务只是从 A 系统取一个字段，按固定公式计算，再写回 B 系统，这本质是数据处理。它需要接口、权限、字段映射和错误处理，不一定需要知识库。

但如果任务涉及判断，就不一样了。

合同要素提取，需要理解不同合同模板里金额、付款条件、违约责任常出现在哪里。预算校验，需要对照公司最新预算规则。审批意见生成，需要参考历史审批口径和常见退回原因。

这些内容会更新，也不适合全部写死在代码或提示词里。它们更适合放进知识库。

知识库也不要一锅炖。合同相关的 Agent，就放合同模板、条款解释、历史争议点。财务校验相关的 Skill，就放预算科目、审批规则、例外处理口径。

如果一个 Agent 跨两个系统，它可以访问两类知识，但调用时要分清楚：什么时候查合同规则，什么时候查预算规则。

知识库的价值不是“让 Agent 看起来懂得多”，而是让可变规则可以被持续维护。

四、提示词不是拿来装懂，它是没有 workflow 时的调度说明书

固定流程优先 workflow；平台不能编排 Skill 时，提示词才承担编排职责。

如果一个流程非常硬：先提取，再校验，校验通过就输出，不通过就退回。最理想的方式，是用 workflow 把它编排起来。

workflow 的好处很直接。步骤清楚，输入输出清楚，失败在哪里也清楚。它不会因为模型“理解偏了”就跳过某一步。

图4：稳定路径画成 Workflow，灵活入口交给 Agent，单点能力沉淀为 Skill。

但现实是，很多智能体平台还没有把 Skill 做成可视化编排组件。你可能已经建好了“数据提取 Skill”和“分析 Skill”，却没有一个画布让你把它们连起来。

这时系统提示词就要承担调度说明书的角色。

提示词里不能只写“你是一个专业助手”。要写清楚：收到任务后，第一步调用哪个 Skill；它的输出必须是什么格式；第二步把哪个字段传给下一个 Skill；遇到缺字段、接口失败、权限不足时怎么办；最终要给人什么结果。

它不是替代工程编排。它是在平台能力不足时，用自然语言把编排逻辑写死。

图5：采购预算预审可以先画成固定 Workflow，再决定是否由 Agent 调用。

这里有一个边界要守住。越是高风险流程，越不要只靠提示词。

付款、授权、审批通过、对外发送、客户承诺，这些动作都要有权限、日志、确认和异常暂停机制。提示词可以告诉 Agent 怎么想，不能替代系统做控制。

五、Agent 建在哪，比建几个更影响使用率

谁在哪个系统里痛苦，Agent 就应该先出现在哪里。

规划 Agent 时，还有一个经常被忽略的问题：它到底出现在哪里？

同样是预算校验 Agent，放在中心化对话框里，和嵌在采购审批页右侧，使用率可能完全不同。

如果用户每天都在 OA 审批页处理采购申请，那 Agent 更适合以侧边栏或嵌入式任务块出现。它读取当前单据，给出校验结论，不要求用户切换页面。

如果任务是跨多个系统找资料、做分析、生成报告，中心化对话入口更合适。因为它的触发不是某张表单，而是一个较完整的问题。

如果任务是低风险、固定规则、无须人工判断，比如每天汇总异常单据，后台自动运行更合适。人只看结果和异常。

不要先讨论界面酷不酷。先看触发源在哪里，用户停留在哪里，AI 需要读什么数据，最后结果要写回哪里。

图6：未来流程要把 AI 活动块、Skill、人工复核和系统写回一起标清楚。

六、从痛点到上线，必须有一张能力盘点表

业务方说不清楚要什么时，不要继续问需求，要让它回答七个格子。

很多业务梳理会失败，是因为大家一直在抽象层讨论。有人说要智能体，有人说要知识库，有人说要自动化，但没人把它落回一个具体流程。

更好的做法，是从一个痛点开始，逐步填表。

第一格，写业务痛点。不是“效率低”，而是“财务每次要登录三个系统查预算，平均十分钟，且容易漏看跨期额度”。

第二格，画现状流程。谁发起，谁处理，在哪个系统，取什么数据，等谁确认，哪里退回。

第三格，画未来流程。左边写角色，角色里要同时有人和 AI；右边写活动，哪些活动由人执行，哪些活动由 AI 执行。

第四格，标 Agent。每一段 AI 连续工作，输入是什么，输出是什么，交给谁。

第五格，标 Skill。每个 Agent 内部有哪些可独立执行的小能力，哪些可复用，哪些只是一次性逻辑。

第六格，标集成方式。它在 OA 页面、业务系统侧边栏、中心化对话框，还是后台定时执行。

第七格，写验收标准。准确率、响应时间、人工复核比例、异常处理方式，都要提前说清楚。

七、最小验证比完整方案更重要

不要等全流程接完，才发现第一个 Skill 根本不准。

规划完 Agent 和 Skill，不代表可以马上大集成。

真正稳妥的做法，是先做最小验证。比如合同要素提取 Skill，先拿 10 到 20 份真实合同测试。金额、供应商、付款条件、违约条款，每个字段都记录提取结果和人工答案。

预算校验 Skill，也不要一开始就接所有系统。先挑一类采购单，固定几个预算科目，把成功、失败、缺字段、接口异常分开记录。

验收标准要尽量业务化。不是“模型效果不错”，而是“关键字段准确率达到约定标准；预算校验能在可接受时间内返回；异常场景能明确提示人工处理；所有调用有日志可追踪”。

这一步看起来慢，其实是在省时间。

因为企业 AI 最怕的不是一开始小，而是一开始大到没人能验收。功能很多，链路很长，最后出了问题，不知道是流程设计错了、Skill 不准、知识库过期、提示词没写清，还是系统接口不稳定。

最小验证的意义，是把风险切小。先验证一个 Skill 能跑通，再验证一个 Agent 能交付，再验证一段流程能闭环。

这样业务方才会从“听懂概念”，走到“知道明天怎么动手”。

八、做 Agent 规划，最好从一个案例题开始

不要先从 Agent 定义出发，先让流程自己暴露边界。

做方法论梳理时，最好先选一个足够小、又足够典型的案例。

比如采购申请审批：采购员填单，财务查预算，部门负责人审批。痛点是财务每次要查三个系统，耗时长，且容易漏看跨期预算。

先回答：这里有几个可 AI 化活动？需要几个 Agent？每个 Agent 里有几个 Skill？为什么？

当这些问题出现分歧，再回到规则：有人介入就是断点；AI 连续且相关可以合并；节点内部有几个可复用步骤，就拆几个 Skill；知识库只放可变规则；平台不能编排 Skill 时，提示词要写清调用顺序。

这比从概念出发更有效。因为方法论不是为了把名词解释清楚，而是为了让一个真实流程变成可建设、可集成、可验收的方案。

企业 AI 的第一步，不是把所有流程都自动化。

第一步是让组织学会一种新能力：把经验从人的脑子里拿出来，放到流程图上，再封装成 Agent 可以调用的 Skill。

这个过程会很麻烦。业务方要讲清楚痛点，流程团队要画出现状和未来，IT 要确认系统接口，管理者要划定权限和风险边界。任何一个环节偷懒，最后都会变成“看起来很智能，但没人敢用”。

所以，别急着问“我们要建多少个 Agent”。

先问：这个流程里，真正让人痛苦的是哪一步？这一步有没有明确输入和输出？它被人工节点打断了吗？它内部有没有可复用的小能力？它需要知识库，还是只需要系统接口？它最后如何被验证？

这些问题回答清楚，Agent 和 Skill 的规划就不再玄学。

它会变成一张可以讨论、可以建设、可以验收的能力清单。