MyAgent
MyAgent 这条线，后来我自己都承认它不是一款足够好的产品。但它对我很重要，因为它非常完整地暴露了我当时的一套判断：在真实的 B 端场景里，很多事情不能完全靠 AI 自己跑完。
原因并不复杂。AI 当然很强，很多时候也确实能把事情做对，但它并不是永远稳定的。它会有幻觉，会走错路，哪怕概率不高，在一些真实业务流程里也不能完全接受。只要这一点成立，问题就不再是“Agent 能不能工作”，而是“怎样让 Agent 在该自由的时候自由，在该受约束的时候受约束”。
这也是我当时为什么会走向 workflow、配置和平台化路线。因为在我看来，workflow 的意义并不只是流程编排，而是给 AI 增加边界、降低幻觉带来的风险、让某些关键步骤变得可控。问题在于，市面上很多 workflow 产品虽然成立，但并不够灵活。很多真实场景并不是纯 workflow，也不是纯 agent，而是两者需要配合。
我当时想做的，就是这样一个中间层：既能承接 Agent，又能承接 workflow，还能通过配置把复杂场景组织起来。
但后来我越来越觉得，这条路虽然问题判断没错，产品方向却做重了。一款真正好的 Agent 产品，不应该像一个需要大量配置和说明书的平台。它更应该像 Claude Code、Codex 这类工具一样，足够简单、足够直接，不需要用户先理解系统，事情就能开始推进。
所以今天再看 MyAgent，我更把它当成一次认知样本，而不是一个要被包装成成功案例的产品。它让我更清楚地看到：AI 产品真正困难的，不只是模型能力，而是如何在“灵活性”和“可用性”之间找到一个不把复杂性甩给用户的平衡点。
一、为什么我当时会觉得平台化是必要的
把一个 Agent 跑起来，在当时已经不难。接模型、接工具、写 prompt，再补一点流程控制，很快就能做出一个看起来像样的 demo。
但问题在于，demo 的成功并不等于产品的成立。只要场景进入真实业务，很多问题就会迅速暴露出来。尤其是在 B 端，一些关键动作不能完全靠 AI 自由发挥。它可能会走错一步，可能会误判一条数据，可能会在不该跳过的地方跳过校验。哪怕这种情况不是天天发生，只要场景足够关键，它就必须被认真对待。
所以我当时很自然地会往平台化去想。因为在那个阶段，我看到的不是“再做一个更聪明的 Agent”，而是“怎么把 Agent 放进真实流程里，还让它尽量可控”。
二、为什么 workflow 在这里有很重要的意义
workflow 在很多人眼里只是流程编排，但我当时看重它，主要不是因为它能把步骤画出来，而是因为它可以承担边界层。
在一些场景里，这件事特别明显。比如数据处理。很多数据可以交给 AI 做理解、分类、提取和补全，但某些步骤又必须有确定性的校验和清晰的执行顺序。再比如审批场景，AI 也许可以做预判、归类、解释和建议，但真正进入关键节点的时候，流程、条件和责任边界都不能只是“让模型自己理解一下”。
所以问题从来都不是“要不要 workflow”，而是“workflow 怎样和 agent 配合”。有些环节适合开放式能力，有些环节适合确定性流程，而更多真实场景需要的是两者混合工作。也正因为如此，我当时会觉得纯 Agent 不够，纯 workflow 也不够，必须要有一个能把它们接在一起的系统。
三、为什么我会觉得现有路线不够灵活
当时市面上已经有一些看起来相近的产品方向，比如 Dify、n8n 这类东西。虽然 MyAgent 和它们并不完全一样，但问题意识上确实有部分相似：都在尝试解决 AI 怎样进入真实流程。
但我当时越来越强烈的感觉是，这些路线并不能很好覆盖我要面对的场景。因为它们通常更适合某一种范式，要么偏 workflow，要么偏固定编排，要么偏工具链连接。可在真实业务里，很多场景需要的不是单一范式，而是 agent 的灵活性和 workflow 的确定性同时存在。
比如一段数据处理，前半段也许是标准流程，后半段却需要 AI 根据上下文判断；某个审批链路里，AI 也许只适合做预处理和信息整理，而不能直接替代规则节点。问题不在于这些产品没价值，而在于它们对“混合场景”的承接还不够灵活。
所以我当时会继续往前走，想做一个更像“中间层”的东西。这个中间层既能承接 Agent，又能承接 workflow，还能通过配置把复杂场景搭起来。
四、为什么我后来觉得这不是一款好产品
今天回头看，我认为 MyAgent 不是一款真正好的产品。
不是因为当时的问题判断错了，而是因为产品最终把太多复杂性暴露给了用户。它需要配置，需要理解系统，需要有人在后台做很多组织工作。哪怕这些配置在逻辑上是合理的，它依然会让产品的第一体验变重。
而一款真正好的 Agent 产品，不应该让用户先学会配置系统，再开始做事。它应该尽量像现在这些更成熟的工具一样，直接、自然、低门槛。用户不需要先看说明书，不需要先理解平台概念，只需要把想法说出来，系统就应该能尽快开始工作。
MyAgent 当时没有做到这一点。它仍然比较依赖专业人士在后台配置，普通用户很难直接进入。哪怕背后的能力是对的，这种上手成本本身就已经是一个很大的产品问题。
五、为什么这个判断后来会变得更明显
还有一个很现实的原因，是大模型进步得太快了。
在 2025 年做这个产品的时候，模型能力和今天并不在一个水平上。那时候我对“流程约束”“配置能力”“平台承载”的依赖，会更强一些，因为我默认模型本身还不够稳定、不够聪明、不够可靠。
但后来模型更新速度远超预期。很多原本需要大量配置和补位的地方，模型本身已经能接住更多。这个变化直接改变了产品成立条件。以前你以为必须靠平台显式暴露出来的复杂度，后来很可能已经应该被系统自己吞掉。
也就是说，MyAgent 不只是产品本身做重了，它还误判了模型进化的速度。这个误判让原本看起来合理的平台结构，越来越像一套不该继续暴露给用户的中间层。
六、MyAgent 真正留下来的判断是什么
虽然我不认为它是一款好产品，但它并不是没有价值。它真正留下来的，是几个对我后续判断很重要的结论。
- B 端场景里不能简单假设 AI 会一直做对，workflow 在很多关键环节仍然有意义。
- 纯 Agent 和纯 workflow 都不够，真正有价值的是两者之间更灵活的配合。
- 正确的问题判断，并不自动导向正确的产品形态。
- 真正好的产品，不应该把系统复杂性直接暴露成用户的使用门槛。
所以 MyAgent 最终对我更像一个认知转折点。它让我更清楚地意识到：Agent 产品真正困难的，不只是把能力搭出来，而是怎样在保留灵活性的同时，把复杂性藏到系统内部，而不是甩给用户自己去配置。