Oracle：从回答问题到完成任务

模型越来越擅长回答问题，但一个更强的回答，并不会自然变成一项被完成的工作。

当用户说“帮我研究一个市场”“做一份完整的方案”或者“把这个想法变成可以使用的东西”时，他交出的不是一个等待补全的句子，而是一个目标。目标通常没有唯一的路径，也很少能在一次生成里结束。它需要搜集信息、理解材料、选择工具、产生中间结果，并根据新的发现不断调整方向。

这也是我们在 Flowith 构建 Oracle 的起点。我们想做的不是让聊天框说得更多，而是让 AI 能够围绕一个目标持续工作。

产品的基本单位应该是任务

对话产品通常以消息为单位：用户输入一条消息，模型返回一条消息，一轮交互就结束了。这个结构适合问答，却很难表达真实工作的状态。

工作有开始、进行、等待、失败、修正和完成。它可能产生多个文件，依赖前一步的结果，也可能在执行过程中发现原来的问题并不准确。如果产品仍然只保存一串消息，这些状态最终只能被藏进文本里，由用户自己理解和管理。

所以在 Oracle 里，我们把目标进一步展开为任务。任务不是为了向用户展示一份看起来专业的清单，而是为了让系统知道：现在正在解决什么、已经获得了什么、下一步为什么值得做。

这个变化看似只是数据结构不同，实际上改变了产品和 AI 的关系。AI 不再只负责生成内容，也开始承担推进工作的责任。

Agent 不是一个更长的 Prompt

早期构建 Agent 时，很容易把所有要求都写进一份巨大的 Prompt：先分析，再计划，然后调用工具，遇到问题就重试，最后整理答案。

但只要任务开始变长，这种方法很快就会失效。模型既要理解目标，又要记住过程，还要管理工具结果与异常。越来越多的上下文被塞进同一次推理，系统表面上更完整，实际却更脆弱。

我们逐渐把 Oracle 理解为几个相互配合的部分：

• 计划负责把目标转化为当前可以推进的行动；
• 工具负责搜索、阅读、生成和处理具体材料；
• 状态负责保存已经发生的事情和仍未解决的问题；
• 反馈让用户能够改变目标，而不必从头开始。

真正重要的并不是这些模块的名字，而是职责不再全部压在模型的一次输出上。模型负责判断，系统负责让判断能够持续发生。

计划是一种假设

我们一开始也倾向于让 AI 先生成完整计划，再依次执行。它提供了秩序，也让复杂任务第一次显得可控。

但计划不应该成为系统必须服从的剧本。搜索结果可能推翻最初判断，某个工具可能失败，用户也可能在中途改变要求。如果 Agent 只是忠实执行最初的步骤，它完成的是计划，而不一定是目标。

因此，计划更适合被看作一种工作假设：它解释系统目前认为应该怎么走，却必须允许新的结果改变下一步。

这也意味着，每一次工具执行都不只是产生一个结果。结果要重新进入判断过程，改变系统对任务的理解。只有形成这个循环，Agent 才不只是自动化流程，而是在工作中持续做决定。

文件不是附件，而是过程的一部分

复杂任务最终很少只交付一段文字。研究会产生资料和结论，创作会产生图片、网页或文档，后续步骤还要继续使用这些结果。

如果文件只是聊天记录旁边的附件，Agent 很难理解它们之间的关系。它需要知道一个文件从哪里来、解决了哪个问题、是否仍然有效，以及接下来谁会使用它。

所以我们开始把中间产物当作任务状态的一部分。它们不仅是最终交付物，也是系统继续思考的外部记忆。

这让我意识到，Agent 产品真正需要管理的并不只是上下文长度，而是工作的连续性。用户离开页面再回来，或者在中途补充新的要求，系统仍然应该知道自己正在做什么。

可靠性来自模型之外

一个模型偶尔能完成复杂任务，并不意味着产品已经可靠。

真实环境里会出现等待、超时、部分失败和重复执行。用户需要知道任务是否仍在继续，哪些结果已经可以使用，以及什么时候必须由人作出决定。这些都不能只依赖模型“记住要处理”。

因此，Agent 的能力不仅取决于推理质量，也取决于它周围的系统是否能够保存进度、约束行动、处理失败并把结果重新交还给判断过程。

我越来越相信：模型决定了系统能够想到什么，产品系统决定了这些想法能否稳定地成为结果。

从回答问题到承担目标

Oracle 对我们而言不是给聊天增加更多按钮，也不是把一组工具包装成 AI。它代表一种产品判断：当 AI 开始拥有计划和行动能力之后，界面、状态、文件与反馈都必须围绕“工作如何被完成”重新设计。

聊天仍然是最自然的入口，但不应该是系统的全部。

真正值得构建的 Agent，不只是能够回答用户接下来应该做什么，而是能够接住一个目标，持续推进它，并让整个过程始终可理解、可修正、可继续。