FDE · Agent Discovery · 2026-09-17
FDE 的新价值：识别业务复杂度，而不是简单交付 Agent
我越来越觉得，Agent 项目中真正困难的第一步，不是“做一个 Agent”，而是判断客户业务中哪些决策值得被 Agent 化。FDE 可能在这里承担重要的牵头角色，但这更像一种正在形成的方法，而不是已经被充分验证的行业结论。
先区分三层：事实、工程判断、未来推测
我的工程判断：因此 Agent 项目应该先识别 Decision Unit，再判断 Automation、Workflow、Optimizer、Copilot 或 Agent 哪种形态合适。
对未来的推测：FDE 可能逐渐从传统交付角色扩展为“业务决策建模”的牵头角色，甚至出现 Agent Discovery Agent 辅助发现可 Agent 化的机会。
1. 客户说“我要一个 Agent”，真正的问题是什么？
客户可能说：“我要解决排产问题。”FDE 不应该马上把“排产”做成一个 Agent，而应该继续追问：到底什么叫排产问题？为什么要重新排？谁在决定？依据什么？有哪些约束？异常有哪些？多久发生一次？错了损失什么？最后怎么知道成功？
最后可能发现，客户真正需要的并不是一个覆盖全部排产工作的 Agent，而是一个只处理“异常恢复”或“插单后的重新分配”的决策单元。
FDE 的价值，不只是把需求翻译成产品功能，而是把模糊业务问题重新建模成可执行、可验证的决策问题。
2. Decision Unit：Agent Discovery 的最小单位
我认为一个 Decision Unit 至少可以描述为：
Trigger
Input / Context
Decision
Constraints
Action
Outcome
Feedback
Risk
Owner / Approver例如“供应商异常恢复”可以被描述成：订单延迟达到阈值 → 输入订单、库存、供应商能力、交期和成本 → 决定是否换供应商/调整数量/调整交期 → 满足质量、成本、交付约束 → 执行动作 → 观察新的交期与库存结果 → 验证是否恢复 → 超过风险阈值时升级人工审批。
一旦把业务拆成这个粒度，Agent 是否适合就比“这个部门要不要 AI”清晰得多。
3. 从 Business Reality 到 Agent Suitability
Business Reality
↓
Process Decomposition
↓
Decision Units
↓
Complexity Map
↓
Agent Suitability
↓
Runtime Design
↓
Outcome Feedback这里真正值得产品化的，不是一个“Agent 按钮”，而可能是一套 Agent Opportunity Assessment。
4. 复杂度不是六个并列标签，而是一个判断框架
我会重点看十个维度：
- 决策频率：决策多久发生一次？
- 参与变量：需要同时考虑多少输入和状态？
- 约束数量：硬约束、软约束和策略有多少？
- 组合复杂度：候选方案空间是否快速增长？
- 状态变化速度：环境是否持续变化？
- 可观测性：Agent 能否获得做决定所需的信息？
- 结果可验证性：能否客观判断行动是否成功？
- 可执行接口成熟度：工具、API、权限和回滚机制是否存在？
- 错误成本：错误一次会造成多大损失？
- 人工决策成本与预期收益：人现在花多少时间，Agent 能节省或创造多少价值？
这十项不是简单相加。可验证性、可观测性和安全边界更接近必要条件；错误成本和治理难度更像风险惩罚项；复杂度、频率和人工成本则更像价值来源。
5. 一个更完整的 Agent Opportunity Assessment
| 维度 | 低 | 中 | 高 | 作用 |
|---|---|---|---|---|
| 决策频率 | 偶发 | 每日 | 持续 | 提高自动化收益 |
| 组合复杂度 | 少量规则 | 多变量 | 方案空间快速增长 | 提高 Agent 潜在价值 |
| 状态变化 | 稳定 | 周期变化 | 实时变化 | 降低静态 Workflow 的覆盖率 |
| 可观测性 | 数据缺失 | 部分可见 | 状态完整 | 接近必要条件 |
| 可验证性 | 主观 | 部分可测 | 结果明确 | 接近必要条件 |
| 错误成本 | 低 | 中 | 极高 | 高风险惩罚 |
| 接口成熟度 | 人工操作 | 部分 API | 工具化且可治理 | 决定能否执行 |
6. Agent 不是默认答案
这也是我对这篇文章原来表达最需要修正的地方：复杂并不自动意味着 Agent。
| 场景 | 特征 | 更合理的形态 |
|---|---|---|
| 固定报表生成 | 低随机、规则明确、错误成本低 | Workflow / Automation |
| 广告素材生成 | 高变化、反馈快、错误成本相对可控 | Agent / Copilot |
| 生产排产建议 | 变量多、约束多、需要验证 | 受控 Agent + Approval |
| 长周期设备维护 | 反馈慢、错误成本高 | 预测模型 + Workflow + Human |
| 核电安全控制 | 高风险、错误成本极高 | 不应直接采用自主 Agent |
这里的结论不是“哪个场景最好”，而是说明：Agent Suitability 必须同时考虑复杂度、验证条件和风险边界。
7. “Workflow 不再经济”需要一个成本模型
文章最后最重要的问题其实是：什么时候传统 Workflow 的维护和决策成本开始超过 Agent Runtime？这不能靠“规则很多”来判断。
Agent 化值得做 ≈
节省的人工决策成本
+ 响应速度收益
+ 业务收益
+ 覆盖更多状态的收益
>
模型调用成本
+ 集成成本
+ 评估成本
+ 监控成本
+ 错误恢复成本
+ 审批成本
+ 解释与治理成本这不是严格的财务公式，而是一个 FDE 做机会评估时应该显式考虑的成本结构。真正要比较的是 Workflow Total Cost 与 Agent Runtime Total Cost，并把错误和治理成本算进去。
8. 不要替代岗位，要替代决策单元
一个岗位往往同时包含 Routine、Decision、Communication、Judgement 和 Responsibility。Agent 最先适合进入的，通常是其中可结构化、可执行、可验证的 Decision Unit，而不是整个岗位。
Supplier Manager
├── Supplier Discovery
├── Supplier Matching
├── Delivery Risk Detection
├── Quality Monitoring
├── Exception Recovery
└── Order Adjustment这比直接设计“Supplier Manager Agent”更容易验证边界、权限和结果。
9. FDE 真正可能变化在哪里？
这里需要避免把 FDE 理想化。现实中的复杂决策识别通常需要 FDE、领域专家、产品经理、解决方案架构师、数据工程师、业务负责人以及风险/合规人员共同参与。
因此更稳妥的说法是：
FDE 可能从“交付协调者”逐渐扩展为业务决策建模的牵头角色，但业务模型、价值判断和责任设计需要跨角色共同完成。
FDE 的特殊价值在于，它同时接触客户现场、产品能力和工程实现，因此适合把这些信息组织成一个可落地的 Decision Model。
10. FDE 作为“业务编译层”
“业务编译器”是我的工程比喻，而不是行业事实。
模糊业务语言
↓
Decision Object
↓
Constraints
↓
Tools / Permissions
↓
Policy
↓
Verification
↓
Exception / Human Handoff
↓
Agent Runtime如果这个比喻成立，那么 FDE 的工作就不只是把客户需求翻译成产品菜单，而是把现实业务“编译”成 Agent 可以执行和验证的决策空间。
11. 一个可能的未来：Agent Discovery Agent
这是推测，而不是已验证趋势。如果企业拥有 SOP、工单、ERP/MES 数据、操作日志、异常记录和人工决策轨迹，未来可能由 Agent Discovery 系统先生成 Business Complexity Map，再由 FDE 与领域专家验证。
Enterprise Data
↓
Agent Discovery
↓
Complexity Map
↓
Agent Opportunity Map
↓
FDE + Domain Expert Validation
↓
Agent Runtime12. 我的暂时结论
已观察事实：Agent 项目需要处理真实业务中的状态、约束、工具和结果，而不是只完成一次 API 调用。
我的工程判断：因此 Agent Discovery 最值得做的第一步，是把 Business Process 拆成 Decision Units，并用复杂度、可验证性、接口成熟度和成本模型判断适配的技术形态。
对未来的推测：FDE 可能逐渐成为这种业务建模过程的牵头工程角色，并与 Agent Discovery 工具、领域专家和治理团队一起形成新的 Agent Opportunity Assessment 流程。
未来判断一个业务是否适合 Agent 化，真正值得问的可能不是“有没有 LLM”，也不是“哪个岗位会被替代”，而是：哪些决策已经足够复杂，传统 Workflow 的总成本开始变高，同时又具备 Agent 所需要的观测、执行、验证和治理条件？
开放问题
- 能否把 Agent Opportunity Assessment 变成可量化的评分/门槛体系，而不是主观打分？
- 哪些条件应该是硬门槛，而不是加分项？
- 如何用真实运行数据估计 Workflow 与 Agent Runtime 的长期总成本？
- Decision Unit 的边界应该如何由 FDE、领域专家和业务负责人共同确认？
- Agent Discovery 能否从日志中发现“隐性决策”，而不只是发现显式 Workflow？