企业 Agentic AI 落地遇冷？拆解人-Prompt-Agent-Skill-流程五元底层逻辑

　　企业 AI Agent 落地遇冷？拆解人 - Prompt-Skill - 流程五元底层逻辑

　　从提示词到意图驱动 读懂 Agent Skill 重塑业务流程真相

　　使用率仅 11% 找准企业 Agentic AI 落地失败核心症结

　　上个月，一位制造业企业的数字化负责人在社区吐槽：公司花了几百万采购了某知名厂商的AI Agent平台，开了三次培训会，发了十几页操作手册，结果三个月过去，平台的活跃用户只有11%。

　　不是员工不愿意用，是真的不知道怎么用。

　　他的困惑很典型：明明看到别人用AI Agent把数据查询时间缩短了95%，把客户响应从42小时压到实时，为什么自己公司就推不动？问题出在哪里？

　　技术选型没问题，预算也给够了，培训也没少做。但有一个更底层的问题没人回答清楚：当AI从"回答问题的工具"变成"执行任务的智能体"，人到底该怎么跟它协作？那些写好的业务流程还算不算数？出了问题谁来兜底？

　　这些问题的背后，是"人-Prompt-Agent-Skill-流程"这条链路上某个环节断掉了。而大多数企业在推进Agentic AI时，压根没意识到这条链路的存在。

　　这篇文章，王吉伟频道就跟大家聊聊的这五个要素之间的真实关系，试着从人-Agent-业务流程的关系路径，对Agent企业落地做一个结构性拆解。

　　从一句话到全局上下文：Prompt的三次跃迁

　　先从Prompt说起。

　　2022年前后，Prompt Engineering作为一个正式职位出现在各大招聘网站，掀起了一波热潮。彼时的主流认知是：谁能写出更好的提示词，谁就能从LLM那里拿到更好的输出。

　　这个逻辑没错，但只对了一半。

　　结构化Prompt确实能显著减少AI错误，Atlan的研究数据显示降幅最高可达76%。但当AI从对话工具演变成执行智能体，仅仅会写提示词这件事，越来越显得捉襟见肘。

　　2025年6月，Andrej Karpathy在X平台发了一条推文，让整个行业陷入了一场认知重构：

在每一个工业级LLM应用中，Context Engineering是一门精妙的艺术与科学，用正确的信息填充上下文窗口，为下一步做好准备。

　　他把Prompt Engineering定义为Context Engineering的子集，而不是全部。几乎同时，Shopify CEO Tobi Lütke也表达了相同判断。Gartner随即在2025年7月宣布：Context Engineering is in, Prompt Engineering is out.

　　这场讨论的核心是什么？Prompt从来不是一句话，它是Agent执行任务时的"认知环境。系统指令、用户输入、历史对话、工具描述、数据库检索结果、当前任务状态，所有这些拼在一起，才是真正意义上的Prompt。

　　到了2026年，这个演变仍在继续。Google Cloud的《2026 AI Agent Trends》报告提出了从 Instruction-based Computing（基于指令的计算）向 Intent-based Computing（基于意图的计算）的范式转移。人类不再是给AI逐条下指令的操作员，而是表达目标和意图的指挥官。

　　所以Prompt经历了三次跃迁，各自有其特定的形态与内涵：

　　第一层：提示词（Prompt as Input）。人写一句话，AI给出回答，是最早的形态，本质是问答交互。门槛低，但能解决的问题也有限。

　　第二层：上下文工程（Context as Environment）。Prompt从"人工输入"变成"系统动态组装"，背后有RAG检索、记忆模块、工具调用描述，是工程化的信息环境。这一层需要真正的技术能力和架构设计。

　　第三层：意图声明（Intent as Goal）。人只需表达想要什么结果，具体执行路径由Agent自主规划，Prompt成了目标描述语言。人的角色从"操作者"升维为"架构师"。

　　这三层不是替代关系，而是包含关系。越往上走，门槛越高，但能解决的问题也越复杂。

　　Prompt有门槛，但Agent Skill把门槛打包进去了

　　Prompt的门槛，到底高在哪里？

　　写一个能让AI稳定输出的Prompt，需要你了解模型的推理方式、任务的边界条件、输出格式的要求，还要反复调试测试。一个企业级的Prompt，往往不是一句话，而是几百行的系统指令。

　　更麻烦的是，这些Prompt本质上是"只有写它的人才能维护"的黑盒。换了人，前任的心血可能就直接报废了。

　　这个问题不是技术问题，是工程化问题。

　　Agent Skill的出现，在某种程度上是对这个问题的一次根本性回答。

　　Codewave对Agent Skill的定义是：将推理、记忆、集成能力和权限组合成可复用工作流逻辑的标准化执行能力单元。

　　换成人话就是：Agent Skill把Prompt、脚本、API调用、数据连接、权限管控、工具调用这一整套东西，打包成了一个可以直接被调用的"能力模块"。

　　从Prompt到Agent Skill，本质上发生了一次从"提示词应用"到"程序应用"的升维。

　　这个升维意义重大。原来你要给AI写Prompt才能完成一个任务，现在你调用一个Skill就可以了。原来Prompt只有写它的人能维护，现在Skill是可复用、可版本管理、可被团队共享的资产。原来每次换模型或者换数据源，Prompt就得重写，现在Skill的接口是稳定的，内部实现可以迭代。

　　更关键的是，Agent Skill把AI Agent的应用门槛和标准化程度都拉高了一个台阶。

　　门槛变高，是因为设计一个好的Skill需要更深的业务理解和技术能力。但同时，使用门槛变低了，因为调用方不需要懂Prompt，只需要知道这个Skill能做什么、输入什么、输出什么。这跟当年软件行业从写汇编到调用API的逻辑是一样的。

　　国内从业者把Agent Skill称为"新时代的软件API"，这个比喻相当精准。

　　软件产业的核心价值，正在从给人用的操作界面，转向给智能体调用的能力单元。企业的核心数字资产，未来也许不再是采购了多少SaaS系统，而是积累了多少高质量的Agent Skill。

　　这句话，值得让每一个从业者认真记住。

　　Agent在"吃掉"业务流程，但流程本身不会消失

　　聊完Skill，必须回答一个更大的问题：企业为什么要用Agent？最终目的是什么？

　　答案是：执行业务流程，完成具体的工作任务。

　　这听起来像废话，但值得深究。

　　传统的业务流程是怎么运行的？它被写死在系统里，靠规则引擎、BPMN流程图、ERP表单，一步一步规定谁做什么、触发什么条件、流转到哪个节点。

　　这套东西的优点是稳定可控，缺点是僵硬。一旦业务规则变了，或者出现了流程图没有覆盖的情况，系统就会卡住，然后等人工干预。

　　AI Agent带来的最大变化，不是替代了某个流程节点，而是改变了流程的执行逻辑。Agent可以感知当前状态，动态规划执行路径，遇到异常情况自主调整，而不是等着被触发。

　　这是从"硬编码的过程执行"到"目标导向的智能编排"的根本性转变。

　　但这里有一个认知误区需要澄清：Agent的出现，并没有消灭业务流程本身。

　　业务流程还在。销售线索跟进还是那几个步骤，采购审批还是需要那几个节点，财务报销还是需要票据和审核。变的不是流程的逻辑，而是执行这些流程的载体。

　　以前流程跑在人的操作上，跑在系统的规则引擎上，跑在RPA的脚本上。现在流程可以跑在Agent上。载体变了，变得更主动、更有判断力、更能应对例外情况，但流程这个概念本身不会因为Agent的出现而消失。

　　用一个不够完美但够直观的比喻：业务流程是一条河道，水还是要从A流到B；Agent是新型的水力调度系统，能根据水位、水速、天气动态调整闸门，而不是靠人工按时间表开关。河道没有消失，流水的逻辑没有消失，变的是调度的智能程度。

　　理解这一点很重要，因为它决定了企业推进Agentic AI时的正确姿势：不是把现有流程全部推翻重来，而是找到哪些流程节点可以用Agent Skill替代或增强，再逐步扩大覆盖范围。

　　从这个角度看，Agent Skill能够应用的业务场景越多，就意味着AI Agent能够胜任的业务场景越多。

　　Agent Skill的应用广度，直接代表了AI Agent在企业中的渗透深度。是一个值得反复强调的判断。

　　Human-in-the-Loop：不是给Agent加绳索，而是给系统装神经

　　AI Agent执行业务流程，听起来很美。但在实际部署中，有一个关键问题必须直面：Agent出错了怎么办？Agent的决策出现偏差，谁来兜底？

　　这就是Human-in-the-Loop（HITL，人类参与闭环）机制存在的意义。

　　HITL的核心逻辑，是在Agent的执行流程中，在特定节点设置人类审核检查点，让人类在必要时介入、修正或批准。这不是对Agent能力的否定，而是对高风险场景的理性设计。

　　BearingPoint合伙人Alfred Obereder有一句话说得很准：它叫Copilot，不叫Autopilot。

　　飞机的自动驾驶系统再先进，驾驶舱里也要有人坐着。不是因为不信任系统，而是因为某些决策的后果，需要有人类来承担。

　　Beam.ai的调研数据显示，88%已经部署AI Agent的企业都发生过不同程度的安全事件。Gartner预测，到2027年，超过40%的Agentic AI项目将因为治理和价值不清晰而被取消。这些数字背后，都有人类参与机制缺失的影子。

　　当然，HITL也有它的代价。在工作流中加入人类检查点，会导致吞吐量下降，自动化效率打折。所以HITL的设计不是越多越好，而是要找到速度与安全之间的平衡点。

　　王吉伟频道认为，HITL的正确设计思路，是按照业务风险等级来划定介入边界：

　　低风险、高频次的标准化操作（比如数据录入、格式转换、常规通知），让Agent全自动执行，人只做事后抽样审计。

　　中等风险、有规则可循的判断性操作（比如客户分级、异常识别、初步报价），Agent执行，超出阈值时自动触发人类审核。

　　高风险、需要主观判断的决策性操作（比如大额合同签署、战略性资源分配、法律合规决策），必须有人类参与批准，Agent只做辅助分析。

　　这个分层框架，其实对应了企业里不同级别的授权体系。把HITL设计和授权管理结合起来，才是真正可落地的企业级人机协同方案。

　　从技术架构的角度，HITL也不再是事后补丁，而是在Agent设计阶段就要考虑的核心架构决策。

　　Microsoft的Agent Framework官方文档已经把HITL作为工作流设计的标准模块，LangGraph等主流Agent框架也都内置了人类介入节点的支持。整个行业正在把"人参与"从可选项变成标配。

　　值得一提的是，SurveyMonkey 2025年的调研发现，即使服务速度和质量完全相同，79%的用户在客服场景仍更愿意与人类互动。

　　这个数字在提醒我们：全面Agentic化并非在所有业务场景都受欢迎，人机协同的边界远比理论复杂，Human-in-the-Loop的设计，永远不只是技术问题，更是信任问题。

　　Skill不只是用，更重要的是"造"：企业专属Skill库的战略价值

　　到这里，我们可以聊一个很多人还没认真想过的问题：企业的Agent Skill，从哪里来？

　　有两种方式，差别极大。

　　一种是采购。买一个Agent平台，平台自带一批通用Skill，开箱即用。SAP在2026年Sapphire大会上发布的Joule Studio 2.0，一口气上线了224个Agent；Oracle也发布了22个Fusion Agentic Applications。这些工厂化生产的Skill，能解决大多数通用场景，但解决不了企业的个性化需求。

　　另一种是自建。把企业自己的业务流程，特别是已经积累多年的标准化操作流程，比如ERP里的采购流程模板、CRM里的销售跟进标准、HR系统里的入职操作规范，转化成企业专属的Agent Skill。

　　后者才是企业Agentic AI真正的护城河所在。

　　这里有一个核心洞察：企业里的Skill，不只是"用"，更重要的是"造"。

　　一个员工接触到一个通用Skill，能完成基本任务，但很可能不顺手，因为它没有考虑到这个员工的个性化工作习惯、部门的特殊业务规则、公司特有的数据格式。

　　真正有价值的事，是让这个员工能够在基础Skill上，结合自己的实际使用场景，不断调试、迭代、升级，把它打磨成真正适合自己的个性化Skill。

　　这个过程，以前是不可能的，因为员工既不会写代码，也不懂Prompt工程。但在Codex、Claude Code等编程智能体出现之后，员工可以用自然语言描述自己的需求，让AI帮助修改Skill的内部逻辑，而不需要自己写一行代码。

　　这是一个了不起的能力转变。它意味着Skill的迭代权，第一次真正下沉到了业务一线。公民开发，也因为Agent Skill而超越过去的RPA变得真正人人可用。

　　这种模式还有一个非常实际的好处：当员工离职或者调岗，他用过的、迭代过的Skill还在那里。新来的员工可以直接继承这套Skill，快速上手，而不是从零开始。这解决了企业里长期存在的"知识在人脑里，人走了知识也走了"的顽疾。

　　而且，当业务流程本身发生变化，比如ERP系统升级、CRM换了新版本、数据源迁移，映射到Skill中的业务逻辑可以随之动态更新，而不是像过去那样重新写一套流程文档、重新培训所有员工。

　　这是Agent Skill为企业带来的最深层的流程变革价值：流程知识，第一次有了可以持续生长、可以传承、可以随环境动态演化的容器。

　　Gartner预测，到2026年底，40%的企业级应用将内嵌AI Agent，而2025年初这个数字不足5%。这个增长速度，背后的基础设施就是Skill体系的大规模建设。

　　五元关系模型：理解Agentic AI的底层逻辑

　　把上面所有讨论整合起来，王吉伟频道尝试构建一个"五元关系模型"，来描述人、Prompt、AI Agent、Agent Skill和业务流程之间的真实关系。

　　人：从执行者到编排者的角色跃迁

　　人（Intent Owner，意图拥有者）是整个体系的起点和终点。人提出目标，定义"完成"的标准，在关键节点作出判断，为最终结果负责。

　　但这里的"人"，跟传统流程里的"人"，已经不是一回事了。

　　McKinsey在连续三篇关于Agentic Organization的报告里反复强调一个判断：员工的角色正在从"in the loop"（在环中）转向"above the loop"（在环之上）。

　　什么意思？以前人是流程的一部分，负责完成某个具体环节；现在人是流程的监督者和设计者，负责设定目标、监控进度、处理例外、评估结果。

　　这个转变，McKinsey用了两个新的人才类型来描述：

　　M型主管（M-shaped Manager）：具备多领域AI应用能力的全能协调者，能够跨部门编排多个Agent协同工作，擅长目标拆解和资源调度。这类人的核心价值不在于精通某个专业领域，而在于理解不同业务场景下Agent的能力边界，知道什么任务该交给谁。

　　T型专家（T-shaped Expert）：在某个垂直领域有深度专业知识，同时具备Agent设计和Skill迭代能力的业务专家。他们负责把领域知识转化成可被Agent执行的Skill，处理Agent无法应对的复杂判断和例外情况。

　　这两类人才的出现，标志着人类在Agentic AI体系中的价值锚点发生了根本性迁移。人的核心竞争力，不再是执行标准化流程的速度和准确度，而是对目标的理解、对异常的判断、对Skill的设计，以及对多个Agent协同的编排能力。

　　这个转变是提升，不是降级。但前提是，人得具备新的能力集。如果一个员工只会按照既定流程填表，不理解业务逻辑，不会设计Skill，那他的价值空间确实会被压缩。

　　这是残酷的现实，也是为什么McKinsey强调企业必须大规模重构人才培养体系的原因。

　　Prompt/Context：动态生成的执行环境

　　Prompt/Context（意图编码器）是人的意图被AI理解的中间层。它不只是一句话，而是人类意图和Agent执行之间的翻译器。

　　在Agentic AI体系里，Context的构建已经高度工程化。一个典型的Agent执行任务时，它的Context可能包括：

　　• 系统指令（定义Agent的角色、能力边界、行为准则）

　　• 用户意图（当前任务的目标和约束条件）

　　• 历史记忆（过往对话、历史决策、用户偏好）

　　• 工具清单（Agent可调用的Skill及其使用说明）

　　• 实时数据（从数据库、API检索到的最新信息）

　　• 任务状态（当前执行到哪一步、遇到了什么问题）

　　这些信息的动态组装，决定了Agent执行的质量。Context设计得好，Agent就能准确理解意图、高效完成任务；Context设计得不好，Agent就会频繁出错或者陷入死循环。

　　这也是为什么Andrej Karpathy会说"Context Engineering才是工业级LLM应用的核心"。在企业场景里，Prompt不是一句话的艺术，而是一套信息架构的工程。

　　Agent：自主感知、规划、行动的执行体

　　AI Agent（意图执行者）是执行体，具备感知、规划、行动、反思的闭环能力。

　　单个Agent的能力再强，也有边界。真正复杂的业务流程，往往需要多个Agent协同完成。比如一个客户投诉处理流程，可能需要：

　　•接待Agent（理解客户诉求，提取关键信息）

　　• 分类Agent（判断投诉类型，路由到对应处理流程）

　　• 查询Agent（从订单系统、物流系统检索相关数据）

　　• 分析Agent（判断责任归属，生成解决方案）

　　• 通知Agent（向客户和相关部门发送进度通知）

　　• 监控Agent（跟踪处理进度，触发升级机制）

　　这些Agent之间，需要协议来打通信息壁垒。Model Context Protocol（MCP）和Agent-to-Agent（A2A）协议的出现，就是在解决这个问题。它们是Agentic AI时代的"TCP/IP"，让不同Agent可以互相理解、互相调用、互相协作。

　　Skill：能力原子与流程知识的封装

　　Agent Skill（能力原子）是Agent能力的标准化封装。它把Prompt、工具调用、数据接口、权限逻辑打包成一个可复用的执行单元。

　　Skill的粒度设计，是一门需要深度业务理解的技术。太粗，灵活性不够；太细，组合复杂度爆炸。最佳实践是，一个Skill对应一个完整的业务能力单元，比如"客户信用评估""库存预警计算""发票自动核对"。

　　Skill的质量和广度，直接决定了Agent的能力边界。一个企业积累了多少高质量的Skill，就意味着它的业务流程有多大比例可以被Agent智能化执行。

　　业务流程：价值交付的载体与终点

　　业务流程（价值交付链）是价值产生的路径，是整个体系运转的最终目的。

　　Agent和Skill服务于业务流程，但并不取代流程本身。销售线索跟进的五个步骤还是那五个步骤，采购审批的三级审核还是要走完，财务报销的票据规则也没有改变。

　　变的是执行方式：从人工操作、规则引擎、RPA脚本，变成了动态智能的Agent体系。

　　流程的逻辑依然存在，只是载体升级了。就像河道还是河道，只是调度系统从手动变成了智能。

　　下面是一个用于财务场景 - 费用报销审批与对账的业级Agent Skill，它的文件夹结构如下：

　　enterprise-expense-approval/
├── SKILL.md
├── references/
│ ├── company-policy.md # 公司费用政策（可定期更新）
│ ├── spending-limits.xlsx # 各部门额度表
│ └── compliance-checklist.md
├── templates/
│ ├── approval-report-template.md
│ └── reconciliation-summary-template.md
├── scripts/
│ └── calculate_tax.py # 可选：税费计算脚本
└── README.md # 使用说明与版本记录

　　SKILL.md 文件内容如下：

　　---
name: enterprise-expense-approval-reconciliation
description: >-
当用户请求处理员工费用报销、审核报销单、验证合规性、生成审批意见、进行账户对账或处理reimbursement、expense report、spending limit相关任务时激活。
适用于企业ERP、财务管理系统或OA平台中的费用管理场景。包含政策检查、金额验证、税务计算、异常处理和审计记录生成。
version: 1.3.0
author: Finance-Compliance-Team
tags: [finance, expense, compliance, approval, reconciliation, erp]
allowed-tools: ["calculator", "search", "email", "erp-connector"]
---

# 企业费用报销审批与对账Skill
## 目的与适用范围
本Skill用于标准化企业内部费用报销全流程处理，确保符合公司政策、税务法规和审计要求。
**适用场景**：
- 员工提交费用报销申请
- 经理/财务审核报销单
- 月度/季度费用对账
- 异常费用处理与审计准备
**不适用场景**：大额资本支出审批、投资决策、复杂税务筹划（需结合其他专业Skill）。
## 触发条件
- 包含“报销”“reimbursement”“expense report”“审批”“对账”“合规审查”等关键词
- 提供发票、凭证、金额或员工信息
- 请求生成财务报告或审计记录
## 执行步骤（决策树）
1. **信息提取**
从用户输入或附件中提取：员工信息、报销日期、金额、类别（差旅、办公、招待等）、发票/凭证信息、项目代码。
2. **政策合规检查**（引用references/company-policy.md）
- 验证金额是否超过部门/职位限额（引用spending-limits.xlsx）
- 检查类别是否允许、单据是否完整
- 识别潜在舞弊风险（如重复报销、异常高额）
3. **金额与税务验证**
- 计算税费、扣除项（使用scripts/calculate_tax.py）
- 验证货币转换与汇率（如跨境报销）
4. **审批决策**
- 符合政策 → 推荐“批准”并生成审批意见
- 部分不符合 → 推荐“条件批准”并列出需补充材料
- 严重违规 → 推荐“拒绝”并说明理由
5. **对账与记录**
- 与ERP系统账户进行匹配（通过MCP工具）
- 生成审计痕迹和汇总报告
6. **输出生成**
使用指定模板输出结果，并记录日志。
## 异常处理与最佳实践
- **缺失凭证**：要求补充并标记为“待补充”
- **超额报销**：自动计算超额部分并建议调整
- **高风险事项**：自动触发额外审批层级并通知合规部门
- 始终保留完整审计轨迹（时间戳、决策依据、操作人）
## 输出格式要求
所有输出必须使用以下结构（Markdown格式）：
**报销审批意见**
**申请人**：
**总金额**：
**合规性评估**：✅/⚠️/❌
**审批建议**：
**需补充材料**：
**对账结果**：
**审计记录**：
## 示例
**输入**：
“张三提交了5000元差旅报销，包含机票和酒店发票，请审核。”
**预期输出**：
（按上述模板生成完整审批意见）
## 引用资源
- references/company-policy.md
- templates/approval-report-template.md
- scripts/calculate_tax.py

**版本历史**
v1.3.0 (2026.05)：增加对账功能与ERP集成
v1.2.0：优化税务计算逻辑

　　这个skill适用于企业管理软件（如ERP系统、财务管理系统、OA系统），可以将企业费用报销流程、合规审查和对账工作标准化，提升处理一致性、合规性和效率，直接复制文件夹结构至Claude Code、Codex、Cursor或GitHub Copilot环境中使用。

　　这样的企业级Skill，对于业务流程自动化程度的快速提升是非常有益的。

　　五元之间的关系网络

　　这五个要素之间，形成了一个单向驱动、双向反馈的关系网络：

　　人输出意图→意图通过Prompt/Context被编码→Agent接收执行信号→通过调用Skill完成业务流程中的具体任务→结果反馈给人→人根据结果调整意图或Skill设计

　　这个循环不断运转，整个系统就在持续优化。但任何一个环节断裂，整个链条就会失效。

　　企业AI项目失败，通常不是模型太弱，而是这条链路上某个环节出了问题：

　　• Prompt/Context设计不当，Agent理解不了人的意图

　　• Skill粒度设置不合理，Agent调用时频繁出错

　　• 业务流程映射错误，Agent执行的逻辑跟实际需求对不上

　　• Human-in-the-Loop节点设置在了错误的位置，要么管得太死导致效率低下，要么放得太松导致风险失控

　　理解这个五元关系模型，是企业推进Agentic AI的认知前提，避免投入技术但难以落地。

　　Agentic AI：一场持续促进融合的过程

　　很多人把Agentic AI理解为更强的AI Agent，这个理解不够完整。

　　Agentic AI，本质上是一场人、Prompt、Agent、Skill与业务流程持续融合、相互重构的系统性变革，而不是某一个技术组件的能力升级。

　　从静态流程到动态编排的范式转变

　　传统工作流是线性的、确定性的。ERP里写了什么，系统就执行什么。业务规则被硬编码在流程引擎里，像一条固定的生产线，每个零件必须按照既定顺序经过每个工位。

　　Agentic AI体系里的流程，是根据目标和当前状态动态生成的。Agent感知到当前情况，评估可行路径，选择最优方案执行。遇到例外情况，可以自主调整而不是卡住等待。

　　这是从"硬编码"到"软编码"，再到"动态编排"的演进。用一个具体案例来说明：

　　传统流程：客户退货处理

　　1. 客户提交退货申请

　　2. 系统检查是否在退货期限内

　　3. 如果是，转人工审核退货原因

　　4. 审核通过后，生成退货单

　　5. 仓库收货，检验商品状态

　　6. 财务发起退款

　　7. 通知客户

　　这个流程写死在系统里。如果客户提交的是换货而非退货，或者商品已经过了退货期但存在质量问题，系统就处理不了，只能转人工。

　　Agentic流程：客户退换货处理

　　Agent接收到客户的诉求（"这个商品有问题，我想退货"），它会：

　　1. 理解客户意图（退货还是换货？问题是什么？）

　　2. 调用"订单查询Skill"，获取订单详情、购买时间、商品信息

　　3. 调用"退货政策Skill"，判断是否符合退货条件

　　4. 如果超期但存在质量问题，调用"质检记录Skill"，查询该批次商品是否有批量质量问题

　　5. 如果有批量问题，触发特殊流程（不受退货期限制）

　　6. 如果客户倾向换货，调用"库存查询Skill"，检查是否有替代商品

　　7. 根据综合判断，生成最优解决方案（退货、换货、补偿）

　　8. 向客户说明方案，征求确认（HITL节点）

　　9. 客户确认后，调用相应Skill执行后续流程

　　整个过程，Agent在动态规划路径。流程不是固定的，而是根据实际情况生成的。这就是"目标导向的智能编排"。

　　Agent在"吃掉"部分业务流程，但流程本身不会消失

　　Agent越来越多地承接原来由人工完成的流程节点，Skill的覆盖范围越宽，Agent能接管的业务场景就越多。

　　但那些业务规则、合规要求、客户关系里的人情判断，这些流程的本质逻辑不会消失。只是执行方式变了，从人工操作、规则引擎，变成了更智能的Agent体系。

　　业务流程不会因为Agent而初步消失，而是以新的形态继续存在。人的价值，从执行流程，转向了设计流程、监督流程、优化流程。

　　Skill库建设：企业Agentic AI战略能力的核心体现

　　技术本身越来越开放，大模型会越来越便宜，Agent框架会越来越成熟。企业真正能形成差异化竞争力的，是自己积累的、经过业务验证的、持续被员工迭代优化的专属Skill库。

　　这个库，买不到，只能自己造。

　　一个企业如果在过去三年积累了200个高质量的业务Skill，覆盖了销售、采购、财务、人力、客服等核心流程，那它的Agentic AI落地速度，会比从零开始的企业快一个数量级。

　　Skill库，是企业在AI时代的新型核心资产。这个判断，值得每一个企业战略决策者认真思考。

　　人的角色重构：从执行者到架构师

　　McKinsey的报告里有一个判断值得反复回味：员工转向编排成果、监督AI Agent、设定目标和管理权衡。

　　这不是降职，而是升维。但这个升维是有条件的：员工得具备理解Agent、设计Skill、定义流程的新型能力。

　　对人的要求变高了，不是变低了。但同时，人的价值空间也变大了。因为从执行变成设计，从操作变成编排，意味着一个人能够调动的资源、能够创造的价值，相比过去有了数量级的提升。

　　HITL：Agentic AI体系可信任、可持续的压舱石

　　速度与安全的平衡，不是非此即彼的选择，而是需要精细设计的工程问题。

　　HITL的价值，不是给Agent加绳索，而是给整个人机协同系统装上了神经系统，让它知道什么时候该自主决策，什么时候该请示上级。

　　这是Agentic AI能够在企业大规模落地的信任基础。没有HITL，企业不敢把关键业务交给Agent；HITL设计不合理，企业又会发现Agent带来的价值远低于预期。

　　找到那个平衡点，是每个企业在推进Agentic AI时必须回答的问题。

　　企业落地的三个真实挑战与破局之道

　　理论讲完了，来说一些接地气的东西。企业推进Agentic AI，在"人-Prompt-Agent-Skill-流程"这条链路上，实际会遇到哪些最常见的坑？

　　挑战一：Skill粒度设计的两难困境

　　问题表现：通用Skill能处理80%的场景，但处理不了那关键的20%。偏偏这20%里，藏着最重要的业务价值。

　　一个真实案例：某电商企业采购了一个"客户咨询自动回复Skill"，平台宣称能覆盖90%的常见问题。实际部署后发现，确实能回答"物流查询""退货政策"这类标准问题，但遇到"我买的衣服褪色了，但已经穿过一次，能退吗？"

　　这种需要灵活判断的情况，就只能回复"请联系人工客服"。

　　结果，客户体验没有改善，人工客服的工作量也没有减少，因为所有稍微复杂一点的问题还是要转人工。

　　破局之道：

　　Skill的粒度设计，需要在通用性和针对性之间找到平衡。建议采用"三层Skill架构"：

　　基础Skill层（Platform Skills）：平台提供的通用能力，比如"文本生成""数据查询""格式转换"，覆盖最基础的操作。

　　行业Skill层（Industry Skills）：针对特定行业的标准化流程，比如"电商退货处理""银行开户审核""制造业质检流程"。这一层可以采购成熟方案，但需要根据企业实际情况做适配。

　　企业Skill层（Enterprise Skills）：企业专属的个性化能力，比如"某公司特有的客户分级规则""某工厂特定产线的质检标准"。这一层必须自建，且需要持续迭代。

　　关键在于：企业不能只停留在基础Skill层和行业Skill层，必须建设自己的企业Skill层，才能真正发挥Agentic AI的价值。

　　挑战二：HITL节点设置的失衡问题

　　问题表现：有的企业什么都要人审，自动化率只有10%，Agent完全成了摆设；有的企业不设任何检查点，Agent在高风险操作上出了错，付出了巨大代价。

　　Beam.ai的调研显示，88%的企业遭遇过安全事件，很大一部分原因是HITL设计不当。

　　一个典型场景：某制造企业部署了"自动采购Agent"，设定规则是"库存低于安全线时自动下单"。某天，系统误判了一个数据（把"1000个"读成了"10个"），Agent判断库存严重不足，自动向供应商下了10倍的订单。等财务发现时，已经签了合同付了定金，造成了几百万的损失。

　　如果在"下单金额超过50万"这个节点设置了人工审核，这个问题本可以避免。但因为企业追求"全自动化"，把这个检查点给省了。

　　破局之道：

　　HITL的设计，应该遵循"风险分级+动态调整"的原则：

　　按金额分级：

　　• 小于1万元：Agent自主决策，人工事后抽查

　　• 1-10万元：Agent执行，超出阈值自动触发人工审核

　　• 大于10万元：必须人工审批，Agent提供决策依据

　　按业务类型分级：

　　• 标准化操作（数据录入、格式转换）：Agent全自动

　　• 判断性操作（客户分级、异常识别）：Agent执行+抽样审核

　　• 决策性操作（合同签署、资源分配）：人工主导+Agent辅助

　　动态调整机制：

　　• Agent在某个场景的准确率达到99%且持续3个月无错误，可以降低人工介入频率

　　• Agent在某个场景连续出现3次错误，立即提升人工介入频率

　　关键在于：HITL不是一次性设计完就不动了，而是要根据Agent的实际表现动态调整，找到速度与安全的最优平衡点。

　　挑战三：Skill孤岛与知识沉淀困境

　　问题表现：买来的通用Skill能用，但用不深、用不精。员工不参与Skill的迭代设计，知识就沉淀不下来。流程变化时，只能被动等平台更新。

　　一个真实场景：某企业的销售部门用了一个"销售线索评分Skill"，根据客户的行业、规模、意向程度给线索打分。用了一段时间，销售团队发现这个评分规则不太准，因为它没有考虑"客户是否有预算""决策周期有多长"这些关键因素。

　　销售主管想调整规则，但发现改不了，因为这是平台提供的标准Skill，不支持自定义。最后只能提需求给厂商，等了三个月出了新版本，但新版本又引入了其他问题。

　　破局之道：

　　企业需要建立"三权分立"的Skill治理机制：

　　创建权（Creation）：业务部门可以用自然语言描述需求，由编程Agent（如Claude Code、GitHub Copilot）辅助生成初版Skill。

　　迭代权（Iteration）：一线员工可以根据实际使用情况，提出优化建议，由技术团队或编程Agent快速迭代。建立"Skill反馈→优化→发布"的快速循环机制，周期不超过1周。

　　治理权（Governance）：IT部门负责版本管理、权限控制、安全审计，确保Skill的质量和合规性。

　　具体落地路径：

　　1. 建立企业Skill库：像GitHub一样，把所有Skill集中管理，支持版本控制、分支开发、合并发布。

　　2. 培养"Skill Owner"角色：每个业务部门指定Skill负责人，负责本部门Skill的设计、迭代、培训。这个角色类似产品经理，需要既懂业务又懂Agent。

　　3. 建立Skill共享机制：销售部门优化的"客户分级Skill"，可能对市场部门也有价值。通过Skill库实现跨部门共享和复用。

　　4. 员工Skill设计能力培养：不是让员工学写代码，而是学会"用自然语言精确描述业务逻辑"。这是Agentic AI时代员工的新型核心能力。

　　关键在于：真正有竞争力的企业，不是买Skill最多的，而是能让员工持续"造Skill"的。Skill库的建设，是一场长期的能力积累，不是一次性采购。

　　尾声：不是终点，而是起点

　　回到文章开头那个制造业CIO的困惑。为什么花了几百万采购的AI Agent平台，活跃用户只有11%？

　　现在我们可以给出答案了：因为他只看到了"Agent"这一个环节，忽视了"人-Prompt-Agent-Skill-流程"这条完整链路。

　　平台买回来了，Agent也部署了，但员工不知道怎么跟Agent协作（人的角色没转变），系统提供的Prompt模板不符合企业实际业务（Context设计不当），通用Skill解决不了个性化场景（Skill库没建设），原有的业务流程也没有针对Agent做适配（流程没重构），更没有设计合理的HITL机制（治理体系缺失）。

　　五个环节断了四个，Agent当然用不起来。

　　到2029年，Gartner预测70%的企业IT基础设施中将部署Agentic AI，而目前这个数字还不到5%。这中间，有巨大的变革空间，也有巨大的不确定性。

　　Agentic AI不是一个产品，而是一种新的企业运营范式。它需要人、技术、流程、组织的协同重构，而不是单纯买一个平台、上一套系统就能完成的事情。

　　人、Prompt、AI Agent、Agent Skill、业务流程，这五个要素之间的关系，是理解这场变革的基础框架。哪个环节想清楚了，落地就会少走一些弯路。

　　Agent在吃掉流程的过程中，其实是在给流程赋予新的生命力。而人，会在这个过程里，从执行者变成设计者，从填表人变成架构师。

　　这个转变，既是挑战，也是机遇。取决于你是在等待变化，还是在设计变化。

　　你的企业在 AI Agent 应用中，是否也遭遇使用率低、流程适配差、人机协同失衡等问题？欢迎评论区聊聊实际落地困扰。持续关注产业前沿逻辑与实战方法，一起探索 Agentic AI 规模化应用路径。

　　McKinsey: [The Agentic Organization] https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-agentic-organization-contours-of-the-next-paradigm-for-the-ai-era)（人类角色重构的权威报告）

　　Andrej Karpathy on Context Engineering: [X Post] https://x.com/karpathy/status/1937902205765607626)（上下文工程的奠基性论述）

　　GitHub: [Context-Engineering Handbook] https://github.com/davidkimai/Context-Engineering)（Karpathy启发的上下文工程实践手册）

　　Codewave: [AI Agent Skills in Enterprise 2026] https://codewave.com/insights/understanding-ai-agent-skills-guide/)（Agent Skill企业应用指南）

　　Microsoft Learn: [Human-in-the-Loop (HITL)] https://learn.microsoft.com/en-us/agent-framework/workflows/human-in-the-loop)（HITL官方架构文档）

　　Google Cloud: [2026 AI Agent Trends] https://zhuanlan.zhihu.com/p/2035082596695160087

　　全文完