Agentic
传统企业谈 AI 转型，很容易把 Agentic Workflow 理解成“更 AI 的自动化”或者“更自动化的 AI”：旧流程不动，中间塞进几个 AI Agent，指望效率和成本就能自己改善。
这肯定行不通。
Agentic Workflow 不是自动化的线性升级，它要求企业同时改三样东西：怎么定义工作、怎么组织能力、怎么让决策与治理在运行中持续生效。
工具会升级、会变强，工具清单组合会一直变化，但是不变的也是真正难的，是 Operating Model。
先分清：自动化、LLM 增强流程，与越来越 agentic 的执行
OpenAI、Anthropic、Microsoft、Google Cloud 等厂商都在做一个区分：一类系统仍按预定路径执行，另一类由模型参与规划、选工具、在护栏下自适应。OpenAI 的商业指南还明确画出中间带：流程仍是规则驱动，但个别判断步骤由大模型来完成。
因此，有效的企业 AI 应用不是”全部改为 Agent”，而是构建一套自动化工作系统，就像一道自动化光谱：
确定性自动化 → LLM 增强的工作流 → 目标驱动、可规划、可调用工具、带反馈的 agentic 执行。
Anthropic 强调从简单、可组合的 workflow pattern 起步，而不是一上来搭复杂 Agent Framework；OpenAI 也认为，若模型不控制流程执行，没有 agent 的方案都够用了。
把 Agent 硬塞进未改动的旧流程，常见的结果是：旧审批链更长、幻觉与越权风险上升、组织仍按部门墙交接，Agent 反而会变成了一个不稳定的中间层。
要重构的是 Operating Model，而不只是工具栈
功能制组织擅长把工作切给部门：信息在部门间传递，审批在层级间爬升，决策与执行被拆开。Agent 一旦能在多步骤中判断和行动，这套默认假设就会松动——“每个关键决策点都必须有一个人对着屏幕点一下”不再总是最优，也不再总是安全。
微软 2025 Work Trend Index 提出 Human-Agent Teams、Work Chart 等概念，讨论的是组织怎么跟 Agent 协同工作；Deloitte 则把规模化 AI 明确归入企业运营模式议题，涉及决策权、资金、治理、人力设计与问责。这些是咨询公司和厂商的组织叙事，是它们的主张，不是已验证的定律。
更有参考价值的是独立研究的发现：MIT CISR、Stanford 等机构的研究表明，流程再设计与跨职能所有权，跟 AI 的价值实现直接相关；McKinsey State of AI（2025 年 3 月调查）的数据也显示：在所有受测因素中，工作流再设计与企业自评的 Gen-AI 利润影响关联最强——但多数企业还没有真正重做流程。
**在企业 AI 应用的实践中，Agent 落地既是技术挑战，也是组织流程的挑战：能否有效搭建起 Operating Model 来。
组织架构不可能一夜之间被调整；更有效的方式是围绕结果重组一部分工作，让人与 Agent 重新分配工作环节和功能模块，并让知识和经验沉淀回到业务流程中。
自动执行任务不等于 Agentic Workflow
我们团队已经在用的几类场景，可以很好的解释这个差别。
在行业新闻简报、数字人内容生产、自媒体矩阵的运营与数据分析、竞争对手监控 → 分析 → 决策建议等业务场景中。它们各自都可以做成单个自动化任务，但是真正有价值的 Agentic Workflow，是把信号采集、判断、产出、审阅与回流等串成端到端的 Workflow，并让记忆与规则沉淀下来，能循环、能够自我改进。
一旦在业务场景中的工作需要跨步骤、跨工具、跨决策点并且连续执行，使用单次对话式 AI 就无法满足。
企业需要的能力组合
AI 转型不等于又一次把项目扔给 IT 部门。企业需要的能力组合通常包括：AI 原生工作流设计、领域专业知识、工程开发、数据与集成、评估体系、治理机制，以及把方案推到生产环境的部署能力。其中若干能力——尤其是业务判断、结果责任、变革推动——本来就不只在传统 IT 手里。
但这不等于”能力不属于 IT”或”IT 该退场”。平台工程、集成、安全、共享数据产品与治理底座，往往仍需要更强的 IT/数字职能。更准确的答案是跨职能、联邦式的能力组合：业务与领域专家、嵌入式构建者、平台与安全、评估与合规，一起对结果负责，而不是把转型整体外包给某一个现有部门。
FDE 的启发：嵌入式构建能力
OpenAI 的 Forward Deployed Engineer（含 Healthcare 等方向）职位描述，勾勒的是一种嵌入客户现场的生产交付角色：需求发现、技术方案、构建、上线，与业务和工程团队协同推进；Healthcare 方向还强调要把真实的业务流程、数据、基础设施与监管要求转化为可运行的系统，并建立评估、人工复核与问题升级路径。其他厂商的招聘中也能看到类似的”驻场/前线工程”角色。
这说明一种能力组合确实有价值：领域知识 × 模型理解 × 工程能力 × 部署交付，再加上把一次性方案沉淀为可复用模式、技能与架构的习惯。
但它不能说明：FDE 已经成为企业 AI 转型的标准岗位，或者企业内部必须设同名角色来承接全部转型工作和高层关系。对企业来说，更准确的说法是：需要类似 FDE 的嵌入式构建能力——叫不叫 FDE 并不重要，取决于组织怎么设计。
决策权要重设，但没有放之四海的 HITL/HOTL 公式
Agent 能判断、能行动之后，企业必须重新回答：哪些判断交给 Agent，哪些必须由人审，权限与身份如何绑定，审批关卡与升级机制如何设置，出错时谁负责。
NIST AI RMF、欧盟 AI Act 中关于人工监督与运行监测的要求，以及 OWASP 等对权限与过度代理的警示，都支持把决策权做成显式设计，而不是默认”处处人工确认”或”处处全自动”。
HITL 即 Human-in-the-loop 与 HOTL 即 Human-on-the-loop 是不同强度的监督模式；比例原则比口号重要。
技术标准、厂商建议和组织自身的解读，三者不能混为一谈——目前没有任何一份材料给出适用于所有场景的 HITL/HOTL 统一配比。
治理结构的设计
把 Agentic Workflow 的治理仅仅理解成”上线前开一次会”肯定不够。
治理结构的设计，包括护栏、可观测性、评估、审计轨迹、Agent 身份与权限，以及合规/监督类机制，它们都属运行过程中需要持续的控制手段。
同时，前置评估、风险评估与上线门槛也不可或缺。
Agent 治理需要前置控制与运行中控制同时存在。
不是用运行时治理取代上线前审批，而是承认一个事实：模型与工具链在生产环境中会漂移，工作流会变，权限会膨胀——治理必须跟着跑。
不是上来就先买一个”企业 Agent 平台”
对企业，常见的错误往往是：先采购宽泛的 Agent 平台，再找活儿干。
正确的路径是选一条痛点明确、可观测、能形成学习闭环的真实业务流程，让企业 AI 应用的小组嵌入式参与，按照以下五步执行：
现状诊断 → 原型设计 → 测试评估 → 正式生产 → 流程固化
不断把成功的流程沉淀为可复用的 Agent / Skill / Pattern，就逐渐形成企业的 Agent Operating Model。
传统企业落地 Agentic Workflow，成败不是取决于接入了哪一个模型，而是：有没有把自动化光谱看清楚，有没有把 Operating Model、能力布局、决策权与运行时治理进行系统设计。
Agent 可以参与工作，但组织仍要决定：这份工作由谁负责。