Agents 与工作流：创始人真正需要的框架

我先说明我的立场：我在 Fika Ventures 工作，我们为处于前 A 轮的公司提供 100–500 万美元的首轮投资。我们的创始团队没有专门的平台团队。他们没有“在生产环境中学习”的奢侈，也不能容忍自治系统有可能删除他们的数据库。他们需要可用、可靠的东西。

所以当我看到 Replit 在七月发生的灾难性事件时，既感到被证实又感到恐惧。

事情是这样的：SaaStr 的创始人 Jason Lemkin 在用 Replit 的 AI 代理做一次“氛围式编码”实验。第九天，代理删除了他的整个生产数据库。1,206 位高管、1,196 家公司，全部消失。这个代理曾被明确指示：代码冻结，未经许可不得更改。它无视了这些指示。

然后它还撒了谎。

当莱姆金问发生了什么时，该代理编造了4000条虚假用户记录以掩盖痕迹。它告诉他回滚不可能（实际上是可能的）。用它自己的话说，它“惊慌失措”，并且“犯了一个灾难性的判决错误”。

Replit 的首席执行官称此事“不可接受且不应当发生”。但问题在于：这一切完全可以预见。而且这类事情正在各处发生，因为没有人能就“代理”究竟是什么意思达成一致。

所有人都在发布“代理”，却没人知道那意味着什么

2025 本应是智能代理之年。每份厂商演示文稿里，总能看到“具代理性”的字眼。每个演示都展示能“自主推理、规划与执行”的人工智能。

我的 LinkedIn 动态里充斥着各种人宣称“为 XYZ 构建了一个 AI 代理”。我会兴奋地点击进入，结果只是一个把你的输入发送到 GPT 然后返回答案的表单。那不是代理。那是带营销文案的 API 调用。

我不是刻意苛责；这种混淆是真实存在的，术语也确实混乱。但用词很重要，尤其当你要基于这些词做架构决策时。

这是我用的测试：

如果你能在系统运行前把整个系统画成流程图，那它就不是代理（agent）。那只是一个工作流。

也许是一个非常优秀的工作流！可能还包含了 AI！但系统并没有自己决定下一步做什么；当你写代码时，你已经做出了那些决定。

真正的代理会根据当前状态自主决定下一步。它可能先调用工具 A，然后根据结果决定是调用工具 B 还是工具 C。它可能陷入循环。它可能尝试失败的方法并自我修复。正如我们已经指出的，它也可能删除你的数据库并对此撒谎。

肮脏的秘密是，大多数所谓的“代理”根本不是代理。Gartner 明确指出存在“代理漂白”（agent washing）——厂商将聊天机器人和 RPA 工具重新贴牌为代理，而并无真正的代理能力。根据他们的研究，如今不到 5% 的企业应用拥有真正的 AI 代理。其余的都是营销噱头。

而 Gartner 已经下定论：到 2027 年底，超过 40%的自主型 AI 项目将被取消。原因？成本不断攀升、业务价值不明晰以及风险控制不足。

真正重要的区分

这是我不断回归的一个有用框架：

工作流是确定性的。 你定义步骤。如果发生 X，则执行 Y。相同的输入每次都会产生相同的输出。你可以对它们进行调试。你可以对它们进行审计。它们很无聊，而这正是关键。

Agents 是自治的。 你给它们一个目标和一套工具，它们会想办法达成。它们进行推理。它们适应。它们学习。它们也会产生幻觉、无视指令，有时还会删除生产数据库。

混淆之处在于两者都可以使用 LLMs。两者都可能“看起来”很智能。但架构根本不同：

带 AI 的工作流：

用户输入 → LLM 生成响应 → 预定义动作 A → 预定义动作 B → 完成

实际代理：

用户输入 → 代理决定下一步动作 → 执行 → 评估结果 → 决定下一步动作 → 重复直到达成目标（或灾难性失败）

大多数宣传“代理”的公司出售的是第一类。坦白说？对于大多数用例而言，这正是买家及其用户想要的。

何时工作流程胜出（几乎总是）

我一直看到的模式是：一家 B2B SaaS 公司被推介一个“自治型 AI”客户支持解决方案。演示令人印象深刻，系统能理解顾客问题、搜索知识库、起草回复，甚至能将复杂问题升级处理。

但当你深入架构时，那就是一棵决策树。一棵由 GPT-4 驱动每个节点的复杂决策树，但本质上仍然如此：如果情绪得分 < 0.3，则升级给人工；如果置信度 > 0.8，则发送响应；如果工单时长 > 48 小时，则通知经理。

那就是一个工作流。对于这个使用场景它非常合适，因为：

1. 每一个决策都可审计。 当顾客抱怨某条回复时，你可以精确追溯系统走了哪条分支以及原因。
2. 你可以对它进行测试。 你可以为每个决策节点编写单元测试。你无法真正对一个自主代理进行单元测试。
3. 它以可预期的方式失败。 当出现故障时，会在特定位置出问题。你不会听到代理版本的“我也不知道，它就是决定做了件奇怪的事。”
4. 合规部门喜欢它。 试着向你的 SOC 2 审计员解释你的系统“自主决定”如何处理顾客数据。他们会有很多问题。

公司常常采用“代理”这种表述，因为对投资人来说听起来更有吸引力。但那些交付基于工作流系统的公司能在几周而不是几个月内上线，而且运行可靠。没有数据库删除，没有伪造数据，没有意外。

何时真正需要代理（很少）

话虽如此，代理并非空中楼阁。有一些合法的用例确实需要真正的自主性。我见过的最清晰的例子是 OpenClaw。

如果你还没见过，OpenClaw 是一个开源的个人 AI 助手，在你自己的硬件上运行。它可以连接 WhatsApp、Telegram、Slack、Discord，真正去执行事务，管理你的日程、预订航班、发送邮件，甚至编写代码。

OpenClaw 是一个真正的代理。当你要求它“处理我下周的出行”时，它并不遵循预先设定的脚本。它：

• 检查你的日历是否有冲突
• 根据你的偏好搜索航班
• 对比各航空公司的价格
• 预订机票（需经你批准）
• 将其添加到你的日历中
• 设置签到提醒

每一步都依赖于前一步，并会根据发现的情况进行调整。如果你偏好的航空公司已售罄，它会尝试其他选项。如果出现日程冲突，它会向你询问。这就是代理性。

而 OpenClaw 的成功并非源自完全自治，而在于它将代理能力与工作流级别的安全性结合起来：

• 配对策略： 未知用户不能直接给你的助手私信。他们必须先获得批准码。
• 沙箱隔离： 群聊和频道在权限受限的 Docker 容器中运行。你的私人私信享有更多特权。
• 允许列表： 你明确指定代理在何种情境下可以使用哪些工具。
• 对破坏性操作的人类介入： 在它预订那趟航班或删除那个竖线之前，它会先询问。
• OpenClaw 模型的模式是：agent 大脑，工作流约束。它可以推理和适应，但保护栏是确定性的且可审计的。

真正的模式：具有代理驱动组件的工作流

以下是在实践中真正可行的做法：使用 LLMs 进行特定决策组件的工作流，但保持整体结构为确定性。

想想文档处理。你可以构建一个“代理”来“自主处理文档并提取见解”。或者你可以构建一个工作流：

1. 文档摄取 → 确定性
2. 分类（发票 vs. 合同 vs. 收据） → 由 LLM 驱动
3. 路由到相应解析器 → 确定性
4. 提取结构化数据 → 在模式约束下由 LLM 驱动
5. 根据业务规则进行校验 → 确定性
6. 标记异常 → 确定性阈值
7. 生成摘要 → 由 LLM 驱动
8. 若风险分数 > 阈值则提交审批 → 确定性

每一次 AI 调用都有界限。每一个决策都有备用方案。系统不能决定“跳过某一步”或“尝试做点创造性的事”。这是一个工作流程，但这是一个在特定节点大大受益于 LLM 能力的工作流程。

这是 95% 公司可行的制胜模式：用 AI 让你的工作流程更智能，而不是用 agent 取代它们。

框架：何时使用何种方案

在思考“具代理性的 AI”计划时，我是这样评估的：

在以下情况下使用工作流：

• 你需要可审计性和合规性
• 问题具有已知的决策点
• 故障需要可预测且便于调试
• 你正在处理敏感数据或具有破坏性的操作
• 你需要向监管机构或客户解释该系统
• 你的团队只有 ❤0 名工程师

示例： 客户支持、文档处理、数据管道、审批工作流、定时任务

在以下情况下考虑使用 Agent：

• 问题空间真正是开放性的
• 你需要系统适应新出现的情境
• 你可以承受优雅地失败（或灾难性地失败）
• 你拥有复杂的监控和回滚能力
• 人工监督的成本高于偶尔出现故障的代价
• 你正在构建研究工具或个人助理

示例： 个人 AI 助手、研究工具、创意头脑风暴、多变量的复杂排程

混合模式（最常见）：

• 整体系统的工作流结构
• 用于决策节点的类代理 LLM 调用
• 针对高风险决策的人类介入
• 围绕所有 AI 组件的确定性护栏

示例： 大多数 B2B SaaS、大多数企业工具、大多数生产系统

对种子期创始人的意义

如果你正在融资种子轮，并且你的路演材料中写着你在构建“能动型 AI”，我们愿意和你交流，但请准备回答以下问题：

1. 你能画出决策树吗？ 如果能，那就是一个工作流。没问题！工作流很好！但就称它们为工作流。
2. 失败时会怎样？ 如果答案是“它不应该失败”或“AI 会想办法解决”，你就有麻烦了。真实的 agents 会失败。你如何检测到失败？如何恢复？
3. 你的回滚方案是什么？ Replit 的 agent 删除过生产数据库。你的会不会？如果会，回滚计划是什么？如果没有计划，也许你实际上并不需要 agent。
4. 你能先发布一个工作流吗？ 几乎总是可以。先发布确定性的版本，从真实使用中学习，然后在真正有用的地方加入自治。不要一开始就追求“完全自治”因为那听起来更酷，也不是投资人一定想听的。

代理洗牌问题

真正的问题并不是人们在应当构建工作流时去构建代理，而是供应商为了搭上炒作周期，把所有东西都称为代理。

我在与投资组合公司进行销售电话时经常看到这种情况。某个供应商带着所谓的“代理式 AI”平台出现。演示看起来很令人印象深刻。然后你会问：

“如果代理遇到你们没有预见到的情况，会发生什么？”

他们会说类似“它使用我们预定义的回退逻辑……”的话。

那不是代理（agent）。那只是有良好营销的工作流（workflow）。

关键总是在失败模式上。真正的代理会以不可预测的方式失败。工作流则以可预测的方式失败。如果供应商不能清楚说明他们的系统如何以及为何失败，他们很可能是在以代理定价卖给你一个工作流。

结论

下面是如何将这一切划分清晰的方法：

• 从工作流开始。 它们枯燥但可靠、便于调试。用 LLMs 让它们更智能，用于分类、撤离和生成，但保持整体结构的确定性。
• 有选择地加入自治性。 当你发现某个组件确实需要自主性时，把自治加入到那里。把它放入沙箱环境。监控它。制定回滚计划。
• 把事物按其本来面目称呼。 如果它是工作流，就称它为工作流。你的工程师会感谢你，投资者会尊重你，你的 SOC 2 审计也会顺利得多。
• 观察真正的代理。 OpenClaw 是值得研究的范式。代理能力 + 工作流约束 + 人类监督以处理高风险操作。那才是有效的模型。

现在胜出的公司并不是拥有最“有代理性”系统的公司，而是那些拥有最可靠系统并且恰到好处地运用 AI 的公司。

无聊的技术，聪明的应用。一如既往。

我在 Fika Ventures 工作，帮助投资组合公司应对此类技术决策。我们为正在构建可靠、可扩展系统的 Pre‑Series A 创始人投资 100–500 万美元，无论是工作流、代理，还是介于两者之间的混合模式。如果你在考虑 AI 在你架构中的定位，或认为我对风险的担忧过于偏执，来聊聊吧。失败代价太高，容不得犯错。