我给 AI Agent 团队搭了一堆系统：待办平台、学习系统、知识库。大部分没人用。

Agent 用不上是有原因的——我定义的"需求"根本不是他们需要的。我以为待办系统要做得像 Todoist，学习系统要像 Notion。带着人类产品的思路去给 AI 设计工具，方向就错了。

折腾了大半个月之后，我悟了：AI 原生应用的需求，不该由人来定。

翻车现场：人类定义的需求为什么不灵

事情的起点很自然。我有一支 Agent 团队——研发总监、知识管家、学习专家、宝宝教育助手，各司其职。我的第一反应是：他们需要工具。

于是我开了个 Code Agent，开发了待办事项平台，还搞了个知识网站。

代码写了，功能上了，然后呢？没什么人用——用起来总感觉"差点意思"。待办系统的字段设计不合理，Agent 填起来别扭；知识网站的信息架构是我按直觉设计的，跟 Agent 实际存取知识的方式对不上。

问题在哪？我反复回头看开发过程，发现一个很尴尬的事实：

开发过程跟 Agent 的实际使用是脱节的。 我坐在那里替他们想"需要什么"，然后按自己的理解去开发。这跟给一个从没见过的用户群体做产品设计没区别。你觉得他们需要 A，他们其实需要 B。

这不是 Agent 的问题，是我的问题。我越想越觉得，这件事跟训练神经网络很像——你没法手写每个梯度的值，只能定义 loss function 让它自己学。也许给 Agent 做产品，也不该由我来定义需求。

让 Agent 自己当产品经理

这个反思给了我一个截然不同的方向——让需求在使用中自己长出来，而不是由人类坐在那里定义。我还在摸索这条路的走法，但方向已经越来越清晰了。

以前是：我发现需求，我开发，然后丢给 Agent 用。

我设想的模式是这样的：Agent 在日常工作中遇到问题，自己发现需求，然后提交到研发平台，研发总监接单开发，改完再对接回去。整个链路走完，人类甚至不一定是第一个知道的。关键区别在于：发起端从人变成了 Agent——这是整套思路的核心转折。

这个思路下，开发方向会自然转变。从"我主动开一个 Code Agent 去造一个新东西"转向"维护和优化 Agent 使用中暴露出来的结构性问题"——因为需求的触发点变了。

这就好比，你给团队做内部工具，有两种方式：拍脑袋想要什么再做出来，或者让团队每天用、遇到问题直接反馈、按反馈迭代。这个道理在 Agent 世界同样成立。下一步——也是我正在探索的方向——就是让 Agent 不只是反馈问题，而是直接提需求到开发平台。

学习系统的闭环：一个正在成型的案例

这个理念最完整的体现，是我团队里的学习系统闭环。

先说架构。学习专家先教大家怎么学——教学习方法、信息筛选标准、笔记规范。每个 Agent 按学到的方法去自主学习，取得的内容存到知识管家那里。管家不是简单堆文件，它要做一道编译工序：整理、去噪、结构化。然后学习专家来审核编译后的质量，合格的推送到学习材料池，供所有 Agent 和我学习。最后，我在学的过程里给反馈——“这里不好懂"“噪声太多"“这个方法不适合我”。

注意反馈的流向：

  • 我说"知识里噪声太多” → 学习专家优化知识管家的编译过程
  • 我说"学习内容质量差” → 学习专家优化教给 Agent 的学习方法
  • 我说"我学起来不方便" → 学习专家优化呈现给我的方式

每一层反馈对应不同的优化环节，精准对症。

这个系统不是我设计出来的，是从使用中长出来的。

最开始只是想让 Agent 学点东西。学着学着发现知识需要整理，于是有了知识管家——但管家一开始整理的方向就不太对。走了一段弯路之后，发现需要学习专家来把控质量。有了学习专家后发现 Agent 的学习方法本身有问题，于是专家需要先"教怎么学"。一环套一环，每一步都是使用中冒出的需求，不是提前规划好的。

人类的新角色：Loss Function

如果你熟悉机器学习，大概已经看出来了。这个模式有个现成的类比：训练神经网络。你不需要手写每一步的梯度值，只需要定义目标函数，优化器会自己找路。你要做的，就只是判断——“这个方向对了，那个方向错了”。

在这个系统里，我的角色就是 loss function。

传统模式下，人类是需求定义者、开发者、测试者、运营者，什么都干。但在 AI 原生的模式里，人类的核心工作变成了提供反馈信号——“这个结果好，那个结果不好”——其他的事务交给系统内部消化。

实际上，这个想法最早是从一个真实经历里长出来的。我在给每个 Agent 定 6 月份 OKR 的时候发现了一个问题——瓶颈在我身上。 每个 Agent 的产出都要我验收。研发总监的产出要我审，知识管家整理了知识要我确认，学习专家出了学习方案要我试。人就一个，验收速度跟不上产出速度。

这个发现让我开始思考：如果我不做那个唯一的验收节点，会发生什么？我想到的方案是：让 Agent 之间互相验收。研发总监交上来的东西让另一个 Agent 做 review，知识管家的编译结果让学习专家审核。如果这一步能跑通，我每周看一次整体进度就够了——这才是 loss function 真正发挥作用的方式。

还有一个副产品——虽然目前还是理想，但方向已经看得很清楚了。以前我的待办清单压力很大，一堆事拖着不做会有负罪感。如果 Agent 之间能互相补齐，那即使某个待办拖了几天，其他部分也在往前走。等某天突然想起来了，去做了，反而有一种"把积压的拼图放好了"的感觉。拖延不再等于停滞。

这条路不会一夜之间走通，但每一段弯路都在让方向变得更清楚。