一个经营分析的 AI 智能化需求背后，产品负责人与 FDE 负责人争论不断。拆解 B 端 Agent 产品如何分层：规则、Workflow、LLM 节点、Agent 各司其职，产品守住稳定解，FDE 承接边界外问题，让共性能力在真实业务里回流产品、沉淀底座。

前段时间在一家做数字员工公司的咨询过程中，我旁听了他们 FDE 负责人和产品负责人一场挺激烈的争论。

他们的问题是：AI 时代下，B 端的 Agent 产品到底应该做成什么形式？以及如何设计才能兼顾可处理问题难度、结果确定性和灵活性？

一个业务的复杂度低的时候，可以保证它的确定性足够高，但当一个业务的复杂度过高的时候，使用工作流缺少灵活性、已经很难维护了，但是 Agent 驱动又很难保证结果确定性。

一开始聊技术，争论的是业务理解到底应该在什么载体上面，Workflow 在哪里承载？数字员工应该怎么定义？

慢慢地聊到产品边界，产品负责人认为，产品一定要有边界，什么能做、什么不能做，必须定义清楚。否则客户每来一个需求，就得重新开发一次，最后做出来的不是产品，只是一套越来越复杂的项目平台。

而 FDE 负责人的观点正好相反，现在的大量 AI 项目本就在产品边界之外，客户不会因为产品只能做到这里，就只提这些问题。

甚至说出了：产品要是实在做不到，我可以不用你的产品来交付。

再往后，一路聊到了交付方法论、平台架构设计、Agent 的商业模式和团队投入。

听起来很散，但背后其实一直是同一个问题：一个复杂、模糊、不确定的客户问题，究竟要怎样才能变成可以规模化交付的产品能力？

这可能也是今天很多 AI 公司需要回答的问题。

压缩不确定性

先回到最传统的软件逻辑。为什么软件企业一定要产品化？

一个业务如果复杂度很低，规则能够说清楚，输入输出明确，异常情况也能够被枚举，那么最好的实现方式就是写程序。

因为程序最大的价值就是确定性，同样的输入尽量给出同样的结果。流程出了问题，可以定位到是哪一个节点，规则需要修改，也可以明确解释改哪里会影响什么。

所以软件产品本质上一直在做一件事情：把无限复杂的现实世界里切出一个有限边界，再把边界内问题的解法进行封装，让这个边界内部尽可能稳定。

包括去年 Coze、Dify 比较火的时候，当时的 AI 项目主流路径：从现实业务到业务规则，到显性化的 SOP，再到由程序承载的 Workflow，再形成标准的产品，最后做商业化、规模化复制。

产品经理在这里面不断做需求抽象、功能设计、流程标准化，其实都是在项目开始交付前就尽可能的减少项目的不确定性。

如果 100 个客户要重复做 100 次调研、设计、开发，它只是一个项目，如果 100 个客户有 80 个客户可以使用同一套东西，它才逐渐成为产品。

扩展问题难度

现实业务其实可以从确定性高到不确定性高划一条线：

规则 → 程序 → Workflow → LLM 节点 → Agent → 业务专家

越往左边越适合通过软件的方式，越往右边越开始依赖理解、判断和探索。

比如规则判断、固定格式的数据处理、状态流转，适合软件。

比如经营分析、复杂的销售跟进，一个问题有多种可能，并不一定能提前写成固定流程。

而且这些事情之所以靠人，不一定是没流程哦，有可能是理完流程才发现：流程里的判断分支多到很难穷举和维护。

业务专家就是内化了这个判断逻辑，总能相比其他人更好更快的定位到问题根因和解决方案。

LLM 节点和 Agent 在这里就是要衔接固定流程和业务专家中间这一部分，解决过去必须由人承担的一部分，现在如何被系统化承接。

有限自由度

但这里很容易产生一个误区：既然 Agent 可以处理不确定问题，是不是复杂业务就不用再理清楚了，把工具、上下文和权限配置好，直接让 Agent 自由发挥就行？

这恰恰是很多 AI 产品设计里最大的误解。

Agent 的价值，不是替代业务梳理，而是承接梳理之后仍然无法完全穷举的部分。

所以更合理的架构：确定性下沉，不确定性上浮。

能写成规则的，不要交给大模型。

能固化成 Workflow 的，不要让 Agent 每次重新规划。

真正无法穷举、必须结合上下文动态判断的部分，才交给 Agent。

这样一来，系统内部的分工就清楚了：

• 规则 / 程序：处理高确定性的逻辑；
• Workflow：承接已经理解清楚的流程；
• Skill / LLM Node：承接局部判断、语义理解和能力调用；
• Agent：负责目标驱动下的动态规划、跨流程组合和剩余不确定性处理。

所以 Workflow 和 Agent 是一种分层协作的模式。

Workflow 负责已经理解清楚的逻辑，Agent 负责暂时还无法完全结构化的逻辑。

而且这两者不是静止不变的。

随着业务理解加深，原来交给 Agent 的一部分判断，还会继续向下沉淀成 Skill、Workflow 甚至规则。

创造性任务能不能进生产

这一点达成共识以后，就产生了下一个问题：我们能否接受不确定性进入生产。

我们在设计和制作一个生产应用的时候，是希望它有一个明确的验收标准的。说白了，如果连最后出来的结果对不对都不知道，怎么敢让它进入生产？

但实际情况是，生产本来就有不可穷举任务，而可穷举任务在 AI 时代之前就被处理了大部分了，AI 项目要面临的大货就是这些不可穷举任务。

比如方案设计、研究分析、路径规划，它们本身就包含探索，只是说，我们原本希望生产系统的责任是建立在结果可确定上的，但很多 AI 任务，我们只能做到风险可控。

传统软件更接近前者：生产可用 = 结果基本可预测

Agent 系统则接近后者：生产可用 = 确定部分足够稳定 + 不确定部分有边界 + 高风险可以发现和接管 + 结果可评估

这样就可以把 AI 生产任务进一步分成三层。

• 确定性任务：由规则 / 程序 / Workflow，目标是稳定执行一类任务。
• 约束型任务：增加 LLM Node 节点进行判断，有明确边界和评价机制，可以随时发现和接管，目标是在约束内提高质效。
• 探索型任务：只有一个可控目标，由 Agent 动态规划、多步探索，目标是提高原来人的能力上限。

这三种东西显然不能使用一种产品设计方法，硬要塞到一套平台里面去，系统必然越来越复杂。这其实也是很多所谓的通用数字员工平台最后不好用的原因之一。

FDE&不确定性

前面解决的是一个已经理解的业务，内部应该怎么分配确定性和不确定性。但如果连业务本身都还没有被结构化，产品又该怎么办。

讨论到这里，产品负责人和 FDE 负责人的角色其实就清楚了：

1. 产品负责人面对的是已经知道怎么稳定解决的问题。
2. FDE 负责人面对的是客户确实有问题，但我们还不知道这个问题怎样才能被稳定解决。

比如客户说，我要做经营分析的 AI 智能化，这其实不算需求，只算一个想法。

继续往下可能会发现没有统一的数据口径，也没有一个经营分析的 SOP，不同管理者关注的问题也不一样。企业想要的甚至也不是一份分析报告，而是发现异常以后的追问、归因和行动建议。

那这个就需要 FDE 先把模糊问题逐步拆清楚：客户目标 → 业务建模 → 现状梳理 → 问题诊断 → 优化方案 → 核心 AI 能力 → MVP

他负责先去现场，帮助客户把产品暂时无法理解的问题，变成一种可以被理解、被验证、被交付的结构。

它属于产品体系前面的不确定性处理层，这也是为什么那场会议里 FDE 负责人敢说不用产品交付。

从纯产品视角听起来，这句话很刺耳，但从 FDE 的职责来看，其实非常合理，因为他首先负责的是：客户目标能不能达成。

边交付边吃业务边完善

传统产品比较理想的状态是先把用户场景需求研究清楚，再定义产品边界，然后规模化去卖。

但现在 AI 场景还没有成熟到这个程度，这个不能单纯定义说产品经理能力不够，很多业务以前根本没有被软件承载过。

销售为什么这么判断？财务负责人为什么追这个指标？这些东西还是以人的经验为主，坐在办公室是没法设计出来的。

包括对于用户来说，如果我们去咨询、去调研，问他什么是对的，他大概率回答不上来，但是我们先做一版可运行的 MVP，谁都能说上两嘴，哪里哪里不对。

所以 B 端 AI 产品可能需要一种不同的生长方式。先基于自己已经理解最深的业务，做出第一个可以成立的数字员工。

把它放到真实客户里面去发现产品的边界，然后 FDE 进入去解决边界外的问题，再把反复出现的共性认知重新吃回产品。产品就在这一轮一轮里慢慢长。

但不是没有边界，还是得先有边界，再不断用真实业务重新验证和扩大边界。

产品之外允许探索，但探索出来的东西回流产品，如果不是一开始就想清楚这个逻辑，或者 FDE 交付的目的不是回流，那还是定制开发。

这个过程可以画成下面这个闭环：

业务长产品、产品长底座

这时候 Agent 底座的位置也很简单。

不用先设计一个万能 Agent 平台，再往里面装业务，应该是当越来越多数字员工和 FDE 项目出现相同的工程问题以后，再把这些公共能力沉到底座。

比如权限、安全、企业系统集成、运行环境、状态管理、监控。

所以完整路径其实只有这一条：

一句话：

业务长产品，产品长底座。

总结

回头看那场 FDE 负责人和产品负责人的争论，两个人其实都没错。

一个关心的是：哪些问题已经可以被稳定解决；另一个关心的是：那些产品暂时解决不了的问题怎么办。

最后可以压成两句话：

确定性下沉，不确定性上浮。

业务长产品，产品长底座。

前一句回答的是，一个 Agent 应用内部应该怎么设计：能规则化的往下沉，不能穷举的留给 Agent。

后一句回答的是，一家 AI 公司的产品体系应该怎么长：先做数字员工，再通过 FDE 进入真实业务，把共性能力持续吃回产品，最后再沉淀公共底座。

所以 AI 产品不是一开始就能被完整设计出来的。

它更像是在真实业务里，一边交付，一边生长。

而 FDE，恰好站在业务探索和产品收敛之间。