最好的 AI Agent 其实都在收敛到四个产品原则

本文整理自 Flinn AI 的一场短讲。演讲者把 Harvey、Cursor、Claude 和 Manus/Manifold 放在一起比较，最后提炼出四个正在反复出现的 agent 产品原则：模式收敛、过程透明、个性化理解，以及可逆性设计。更值得看的地方不在于概念本身，而在于这四条几乎刚好对应了 AI agent 从 demo 走向可验证系统时最关键的治理问题。原视频：https://www.youtube.com/watch?v=7CrPrHgoEYk

这场分享到底在讲什么

这段视频很短，只有十分钟出头，但信息密度不低。Mardu Swanepoel 想回答的问题很直接：如果把今天市面上一些做得比较像样的 agent 产品放在一起看，它们有没有一些共同结构？

他的答案是有，而且不是模型层的共同结构，而是产品层和治理层的共同结构。具体说，就是四个模式：

• Focus modes：把 agent 放进更窄的任务模式里
• Transparent execution：把执行过程显出来
• Personalization：让 agent 更快理解用户真正想要什么
• Reversibility：让错误的成本可控、可撤销

这个提炼本身不复杂，但它有价值的地方在于：它把“一个 agent 为什么看起来更靠谱”拆成了四个可以设计、可以验证、也可以对照竞品观察的抓手。

第一条：不要一上来就做万能 agent，而是先做模式收敛

演讲者说的第一条是 focus modes。意思不是“多做几个按钮”，而是先承认一个现实：大而全的“你问我什么都行”界面，往往既让用户期待失真，也让工程优化无从下手。

把 agent 收进 planning mode、research mode、debug mode 这种更窄的模式里，最直接的收益有两个。

第一，是工程收益。动作空间变小之后，system prompt、工具集、评测集、失败画像，都更容易收紧。你不需要在一个巨大的 action space 里赌模型自己稳定发挥，而是先在一个小得多的空间里把质量打磨出来。

第二，是交互收益。很多用户并不知道怎样提问，才能把 agent 的效果逼出来。模式本质上是在帮用户收窄任务，也是在帮产品提前对齐预期。你选了 planning mode，就默认接受“它先给计划，不直接改代码”；你进了 debug mode，也更容易接受它会先建假设、看日志、排查根因，而不是上来乱改。

视频里举的典型案例是 Cursor。它把不同模式显式放在界面上，不同模式对应不同的行为边界。这个设计看着像 UI 小功能，实际很像一层轻量治理：先把问题变成一个更可验证的小系统，再让 agent 去跑。

这和我在自己的知识库里长期强调的一个原则很接近：先定义验收，再开始实现；先跑最小闭环，再扩范围。所谓 focus mode，本质上就是把 agent 从“抽象承诺”拉回“局部可验证”。

第二条：过程透明，不只是为了好看，而是为了把代理改成协作

第二条是 transparent execution。Mardu 的说法很准确：目标是从 delegation 走向 collaboration。

很多 agent 产品的问题，不是它不会干活，而是它干活的方式对用户来说太黑箱。你把任务交出去，过一会儿它吐一个结果回来。这个结果也许对，也许错，但用户不知道它读了什么、用了什么工具、沿着什么假设往前走，更不知道它哪些地方其实没把握。

透明执行解决的就是这个问题。

它至少带来两个实际收益。

一个是信任。不是靠“请相信我”，而是靠把过程摆出来。工具调用、输入输出、任务列表、已完成步骤、接下来的步骤，这些一旦可见，用户对结果的判断就有了依据。

另一个是止损。很多错误并不是最后一步才发生，而是在第二步、第三步方向就偏了。如果用户能早一点看到 agent 读错文档、选错资料、走错路径，就能更早介入，减少无谓消耗。

视频里把 Claude 和 Manifold/Manus 放进这个例子里。Claude 这一类产品会显式展示 todo/progress、调用了哪些工具、工具的输入输出是什么；Manifold 也会展示任务推进和它具体看过什么。这种透明化不只是“给用户一个热闹的界面”，而是在把 agent 的执行痕迹外显成一个可以被审计、被打断、被修正的过程。

这点和 AKSOUL 里那套 verifiability first 其实是同一脉络：没有检查、没有失败画像、没有执行证据的完成，不算真正完成。透明执行不是锦上添花，它是在给 agent 补可审计性。

第三条：真正稀缺的不是生成速度，而是理解速度

第三条是 personalization。这个词很容易被做成“记住你的昵称”“知道你的偏好颜色”那种浅层记忆，但视频里强调的重点更值得记：agent 不只是要快点出结果，而是要快点理解你。

Mardu 把这个叫 speed to understanding，而不是 speed to outcome。我觉得这个区分非常关键。

因为很多 agent 已经能很快生成一个像样的输出，但“像样”不等于“对路”。如果它没有真正吃到你的目标、边界、审美、历史做法、默认取舍，它再快，也只是更快地产生偏题结果。

所以 personalization 的价值，不是让 agent 看起来更贴心，而是减少来回校正的成本。真正有效的个性化，应该把用户平时怎么判断、怎么取舍、怎么组织信息，变成 agent 可以调用的局部系统。

视频里举了两个例子。

一个是 Harvey 的 playbook。法律事务所平时审合同有自己的一套方法、顺序和原则，Harvey 会把这套方法变成 playbook，让 agent 不是“泛泛地审合同”，而是“按你们这家律所的方式审合同”。

另一个是 Claude 这类产品里的 memory、skills、connectors。它们本质上都不是装饰功能，而是在给 agent 提供用户本地化的判断框架、知识接口和稳定约束。

这个角度跟我自己最近越来越确认的一点也很像：知识工程里真正值钱的，不是再多加一层抽象，而是把本地真实上下文变成可执行接口。文档、技能、记忆、工具连接器，都是为了缩短 agent 从“会回答”到“懂你想怎么做”的距离。

第四条：如果不能撤销，很多高价值任务用户根本不敢交给 agent

第四条是 reversibility，也就是可逆性。

很多 agent 产品喜欢强调效率，但真正影响用户是否敢把高价值任务交出去的，往往不是效率，而是“做错了以后代价有多大”。

如果一件事做错以后很难回滚，用户天然就会保守。他会把 agent 限制在低风险、低价值的边角任务上，不愿意让它碰真正重要的内容。反过来，只要系统能把错误代价压住，用户就更愿意把 agent 用到更高价值的地方。

Mardu 对这一点的表述很干脆：reversibility 的作用，就是 bound the cost of mistakes。

视频里最典型的例子还是 Cursor。它的撤销不是只有一个大而粗的“回退”按钮，而是多层粒度：

• 可以按行接受或拒绝改动
• 可以按文件接受或回滚
• 可以回到某个会话状态点
• 甚至可以基于同一输入并行跑多个模型输出，再保留一个、撤销其他

这套设计的价值，不在于让产品看起来“高级”，而在于把试错从危险行为变成可管理行为。你知道最坏情况可以回去，于是你才敢放手让 agent 多做一点。

Harvey 在 Word 插件里借原生修订能力做变更可视化，其实也是同一件事：不要只让 agent 动手，还要让用户可以像编辑一样审、退、改。

这条跟系统工程的回滚观念没有本质区别。一个不能回滚的 agent，不适合进入严肃生产环境；一个回滚边界清晰的 agent，才有资格去接更高价值任务。

这四条放在一起看，指向的不是“更聪明”，而是“更可治理”

如果把这四个模式连起来看，会发现它们其实覆盖的是同一条主线：怎么把 agent 从一个偶尔给你惊喜的黑箱，变成一个可以稳定协作的系统。

• Focus modes 解决的是边界问题：先收窄任务空间
• Transparent execution 解决的是审计问题：让过程可见
• Personalization 解决的是对齐问题：让 agent 更快理解你的真实意图
• Reversibility 解决的是风险问题：把错误代价限制住

这四条凑在一起，刚好对应一个 agent 系统真正进入生产使用前最核心的四个治理维度：边界、证据、对齐、回滚。

这也是为什么我觉得这场十分钟短讲比很多“agent 未来会改变世界”的泛泛演讲更有价值。它没有再去喊口号，而是给出了一套观察框架：你以后看到任何一个 agent 产品，都可以顺手问这四个问题。

1. 它有没有把任务模式收窄，还是继续 pretending 自己什么都能做？
2. 它的执行过程到底有多透明，用户能不能中途介入？
3. 它是真的在理解用户，还是只是在记住几个表面偏好？
4. 它做错事之后，回滚成本有多高？

问完这四个问题，很多产品的真实成熟度就暴露出来了。

我自己的补充判断：2026 年的 agent 竞争，重点已经不只是模型能力

如果只看这场分享本身，它是在做产品 pattern 的归纳。

但再往前推一步，我更关心的是：这些 pattern 为什么会同时在不同产品里出现？

我的判断是，行业已经开始从“谁的模型更强”转向“谁更懂得把模型包进一个可治理的系统里”。模型能力当然仍然重要，但到了 agent 这一层，真正拉开差距的往往不是单次回答质量，而是系统有没有把以下几件事补齐：

• 把高自由度问题压缩成可控模式
• 把执行过程变成用户可见资产
• 把用户经验沉淀成可复用知识接口
• 把错误从灾难变成可撤销试错

也就是说，agent 产品正在越来越像软件工程，而不是越来越像聊天机器人。

这也是为什么 Harvey、Cursor、Claude、Manus/Manifold 虽然面向的场景差异很大，最后却会在这些点上收敛。不是大家互相抄作业，而是只要你真的把 agent 往生产场景推，最后迟早都会撞到同几类问题，然后被迫长出相似结构。

这段视频最值得抄的，不是结论，而是观察方法

视频一开始引用了毕加索那句老话：好的艺术家模仿，伟大的艺术家偷窃。这里的“偷”不是生搬硬套，而是看懂别人为什么这么设计，再把背后的结构抽出来，变成自己的能力。

我觉得这也是看 agent 产品最对的姿势。

不要只盯着某个按钮、某个炫技 demo、某个发布会口号。更重要的是拆它背后的系统设计：它怎样收边界，怎样给证据，怎样做对齐，怎样控风险。把这些结构看懂之后，你不只是更会评价 agent 产品，也更知道自己该怎么做下一代内部工具、团队工作流，甚至知识系统。

这才是这场短讲真正值钱的地方。