Agent Apps：Agent 时代，大家都在造工具箱，但真正缺的是“工作台”

Agent Apps：Agent 时代，大家都在造工具箱，但真正缺的是“工作台”

这两年，几乎所有人都在聊 Agent。

有人卷模型。
有人卷 Prompt。
有人卷 Workflow。
有人卷 Tools、Skills、Memory、Planning。

看上去大家都很忙，也都很有道理。

但我越来越觉得，这个方向里有一个特别关键的东西，一直没人真正讲明白：

我们缺的不是更多工具。
我们缺的是 Agent 的 App。

不是给人用的 AI App。
不是一堆工具打包起来换个壳。
也不是那种“一个 Agent 包打天下”的大一统幻觉。

而是一层一直存在、但始终没被单独命名的东西：

Agent App。

如果这一层不被单独拎出来，接下来很长一段时间，大家都会重复掉进同一个坑：

Demo 做得飞起，系统一落地就开始散。

现在的 Agent，最大的问题是什么？

一句话：

它有手，但没有工位。

今天大多数 Agent 系统，底层都是同一个套路：

给模型接一堆 tools，
再给它一个 loop，
让它自己规划、自己调用、自己执行。

这套东西在小任务上当然能跑。
查个资料，改段代码，写个总结，都没问题。

但只要任务一变复杂，问题立刻就来了。

为什么？

因为真实世界里的工作，从来都不是“连续调用几个函数”这么简单。

程序员不是靠 read_file + write_file + grep 工作的。
程序员是在 IDE 里工作的。

分析师不是靠 query_data + calculate + export 工作的。
分析师是在表格、看板、报表里工作的。

运营也不是靠 search + send + update_status 工作的。
运营是在工单、队列、后台、工作区里工作的。

说白了：

人类不是直接使用能力完成工作的。
人类是通过“应用”这个中间层，把能力组织成可操作的环境。

Agent 现在最缺的，就是这个环境。

什么叫 Agent App？

我更愿意用一句人话来解释：

Agent App，不是给 Agent 一个按钮。
而是给 Agent 一个能干活的界面。

注意，这里的“界面”不是视觉上的 GUI。
重点不是长得像桌面。
重点是：它是不是一个可操作、可理解、可持续工作的环境。

一个真正的 Agent App，至少得有这几样东西：

它有状态。
不是调完一个函数就什么都不剩了。

它有上下文。
知道“我现在在哪”，而不是永远从零开始。

它有结构。
不是一坨文本喂给模型自己猜。

它有视图。
不同阶段，该看到什么，不该看到什么，是有组织的。

它有动作，而且动作和当前上下文是绑在一起的。
不是任何时候都把一整个工具列表甩给模型。

所以最简单的理解是：

Tool 给 Agent 的，是“能做什么”。
Agent App 给 Agent 的，是“现在该在哪做、照着什么做”。

前者是能力。
后者是工作现场。

这就是两者最大的区别。

为什么说它不是传统 App？

因为传统 App 从第一天开始，就不是给 Agent 设计的。

传统 App 默认谁在操作？
人。

所以它天然假设：

• 你看得懂界面
• 你知道按钮是什么意思
• 你能从布局、颜色、层级里脑补语义
• 你会自己判断下一步该点哪里

这些东西，人类当然没问题。

但 Agent 不行。

对 Agent 来说，一个界面如果只是“长得合理”，那是没用的。
它需要的是另一种东西：

• 当前有哪些对象？
• 当前在哪个视图？
• 现在有哪些动作是合法的？
• 这些动作分别作用于什么？
• 做完之后，状态怎么变了？
• 哪些信息该保留，哪些信息该丢掉？

也就是说，传统 App 优先服务的是“人类感知”。

而 Agent App 优先服务的是“机器操作”。

这两者看起来像一家人，底层假设其实完全不是一回事。

为什么它不是 tool collection？

很多人一听这个概念，第一反应就是：

“哦，不就是把 tools 包装得更好一点吗？”

不是。差远了。

tool collection 本质上是什么？
就是一张能力清单。

比如：

• 搜索
• 读取
• 写入
• 调接口
• 发消息
• 改状态

这当然重要。
但它只解决了一件事：

Agent 能做什么。

它没有解决另外几件更关键的事：

• Agent 现在到底身处什么场景？
• 它眼前看到的世界是什么结构？
• 这一步最相关的操作是哪些？
• 不同动作之间是什么关系？
• 上一步动作造成了什么影响？

工具集合像什么？

像把一大箱扳手、螺丝刀、电钻丢在地上，然后告诉 Agent：
“来，开始修房子吧。”

但 App 像什么？

像你把施工图、当前进度、材料区、操作台、危险边界、可执行步骤，全都整理好了，然后再让它开工。

一个是“你手里有什么”。
一个是“你现在到底在干什么”。

这根本不是一层东西。

所以我一直觉得，很多团队不是 Tool 不够多，而是太迷信 Tool 了。

好像工具越多，Agent 就越强。
其实很多时候，工具越多，Agent 越容易迷路。

为什么它也不是 skills？

skills 比 tools 更高级一点，但还是不够。

因为 skill 解决的是“怎么做一类事情”，不是“你在什么环境里做这件事”。

比如：

一个 skill 可以教 Agent 怎么 review PR。
一个 skill 可以教 Agent 怎么写研究总结。
一个 skill 可以教 Agent 怎么排查一次线上故障。

没问题。

但 skill 大多数时候解决的是流程经验，是套路，是方法论。

它像一个熟练工人的经验包。
它告诉你这活一般怎么干，先看什么，后看什么，出了问题怎么办。

可问题是，经验再丰富，也得有工位。

你不能把一个技能包扔进真空里，然后指望它稳定发挥。

没有应用层，skill 最后会变成什么？

会变成一锅越来越稠的提示词汤。

今天补一句 instruction。
明天加一段 tool doc。
后天再塞一个 heuristic。
再后天多来一层 router。
最后整个系统看起来像能跑，实际上维护的人每天都在赌命。

所以这几层最好分清楚：

tools 是手脚
skills 是经验
agents 是大脑
Agent Apps 是工位

少了工位，手脚再多，大脑再强，最后都容易原地打转。

为什么一定要把这一层单独命名出来？

因为一个东西只要没被命名，它最后就一定会被“糊”在别的层里。

然后整个系统开始畸形发育。

现在行业里最常见的两种畸形，我觉得特别典型。

第一种：工具大爆炸

遇到问题怎么办？

加 tool。
再加 tool。
继续加 tool。
再把 tool description 写长一点。
再加一点 metadata。
再做一层 wrapper。

结果就是：

工具一箩筐，
系统还是没脑子。

不是不会调用，
是根本搞不清自己现在身处什么状态。

第二种：把一切都塞进 Agent

既然 tools 不够，那就增强 agent。

Prompt 写长一点。
Context 喂多一点。
Planning 做复杂一点。
Memory 挂多一点。
Router 再智能一点。

结果就是：

看起来越来越高级，
其实越来越像一团屎山。

为什么？

因为本来该由“应用环境”承担的职责，被你硬塞进了 Agent 本身。

该由环境提供状态。
你让 Prompt 去背。

该由环境约束动作。
你让模型自己悟。

该由环境组织视图。
你让上下文自己拼。

最后当然会越来越脆。

所以“Agent App”这个名字的价值，不只是为了造新词。
而是为了逼着大家承认：

这里本来就该有一层。

这层不属于 tool。
不属于 skill。
也不该塞进 agent loop。
它就该是一个独立层。

一旦承认 Agent App 是一层，很多事情会瞬间变清楚

首先，Agent 会更稳。

因为它不再面对“一大坨文本 + 一大串工具说明”。
而是在一个有边界、有状态、有合法动作集合的环境里工作。

这两种系统，稳定性根本不是一个级别。

其次，架构会变清楚。

你会自然地把系统拆成几层：

• runtime 负责跑环境
• SDK 负责定义 state / view / action
• agent driver 负责理解上下文、驱动执行
• app 本身负责领域内的交互逻辑

这时候系统是能长大的。
不然最后一定长成 framework spaghetti。

再往后，生态也会变。

因为一旦“App”这层成立了，你构建的就不再是“给 Agent 配工具链”。

你是在构建一套Agent 原生的软件生态。

给 Agent 用的 IDE。
给 Agent 用的 spreadsheet。
给 Agent 用的 research workspace。
给 Agent 用的 ops console。
给 Agent 用的 support desk。
给 Agent 用的 planning board。

很多人现在还在争：“Agent 会不会吃掉 App？”

我觉得更可能的答案是：

Agent 不会吃掉 App。
Agent 会催生出一批新 App。

只是这些 App，不再以人类操作为第一前提。

多 Agent 为什么一直做得别扭？问题可能也在这里

现在很多人一聊 multi-agent，马上开始聊分工、通信、协作、投票、博弈。

这些都没错。
但很多讨论都太着急了。

因为多个 Agent 要协作，前提不是“会不会互发消息”。
前提是：它们有没有一个清晰的工作表面。

如果没有共享状态，
没有明确边界，
没有可追踪的状态变化，
没有对齐好的上下文视图，

那你所谓的协作，最后大概率就是几个人在一个黑屋子里喊话。

喊得很热闹，事没怎么推进。

Agent App 恰恰提供的，就是这个“工作表面”。

它让协作不再只是 message passing，
而是建立在一个明确环境之上的状态协同。

这才像真的在工作。

最后，用一句最土但最准的话总结

如果一定要把这几层说得再直白一点，那就是：

Tools 是工具箱。
Skills 是老师傅的手艺。
Agents 是会动脑子的操作员。
Agent Apps 是它真正上班的工位。

过去大家太迷恋“给 Agent 多装点能力”。

但能力从来不是全部。

一个人再有本事，
你把他扔进一个没有桌子、没有流程、没有面板、没有上下文的空房间里，
他也干不好活。

Agent 也是一样。

所以我越来越相信：

下一代 Agent stack 里，真正值得被单独拎出来讨论的，不只是模型，不只是工具，不只是工作流。

而是这一层——

Agent Apps。

因为它补上的，不是某个功能。
而是 Agent 真正开始“上班”所需要的环境。

说到底，Agent 不是只需要一双手。
它需要一个工位。