Cherry Studio v2 重构后，从 Chat 转向 Agent 产品，重写底层数据与任务体系。本文深入分析 AI 产品价值单位从回答变为结果，Chat 架构的局限，以及为何所有 AI 产品都必须拥抱 Agent 形态，值得每位产品人关注。

最近体验了 Cherry Studio 重构后的 v2 版本，我第一次感觉到，这是一款今年所有做 AI 产品的公司都必须认真学习的 Agent 产品。因为接下来的 AI 产品，必须做成 Agent 产品

我的判断很明确。过去的 AI 产品把模型装进聊天框，用户提出问题，产品给出答案。现在，用户开始把完整任务交给 AI，希望它找到资料并调用工具，遇到问题后还能调整，最后交付一个可以验收的结果。产品如果停留在回答这一层，模型能力再强，用户仍然得亲自管理整个过程

Cherry Studio v2 把这种变化落实到了产品结构中。Agent 没有被放在原有 Chat 产品旁边当成一个新入口。团队直接重写底层数据与任务体系。产品开始围绕用户目标组织能力，系统承担从目标走向结果的复杂过程

一个成功的 Chat 产品，为什么要推倒重来

2024 年，Cherry Studio 开始做一件当时很合理的事。它把不同大模型放进同一个桌面客户端，让用户少打开几个网站，也不用重新适应每家产品的界面。选模型，发消息，存会话。这套产品很好懂，数据也简单，核心围绕消息和会话展开

后来，Cherry Studio 接入了知识库与联网搜索，MCP 等能力也陆续进入产品。工具齐了，用户的工作却变多了。他要知道哪个模型更合适，还得决定什么时候调用搜索或知识库。产品把能力摆到界面里，怎么组合仍由用户负责

按照创始人 Yinsen 的复盘，团队逐渐发现，原来为 Chat 设计的架构已经很难承接持续执行的任务。一次任务会读取多个文件，中间结果改变后需要调整方向。某个工具调用失败，系统还得从已完成的位置继续。这些动作共享一个目标，任何一步都可能改变后面的路径。消息记录只能告诉系统说过什么，它表达不了任务做到哪里，也不知道失败后应该从哪里恢复

Cherry Studio 最后选择重写底层数据与 Agent 运行体系。2026 年 8 月 5 日，2.0 正式版发布，官方将它定位为从 Chat 走向完成工作的 AI 工作空间。新架构给 Agent 会话提供独立运行时，执行状态可以持久化，工具审批也进入底层体系

代价不小。这次重构发生时，1.x 仍然有用户在工作中使用。按照团队的说法，他们一边维护旧产品，一边建设新体系，相当于同时承担两套产品的开发与维护。一个已经拥有用户和功能积累的 Chat 产品，仍然愿意为 Agent 重做数据与任务结构，原因已经超出了功能追赶

产品当初承诺的是让用户更方便地使用 AI，现在需要承接的是让 AI 帮用户完成事情。当一次回答无法代表用户价值，继续优化 Chat 窗口也补不上任务交付的缺口

一、AI 产品的价值单位，已经从回答变成结果

用户对 AI 说，帮我整理公司的历史资料，分析市场变化，最后交付一份可以继续修改的报告。一句话背后，是一串没有固定路径的动作。系统先要找到资料的位置与时间范围，遇到信息缺口后再搜索外部来源。材料齐了，它还要区分事实和判断，并根据用户的目的组织报告。产物交付以前，系统需要检查结果是否符合要求

Chat 产品通常把这个过程切成很多轮对话。用户先上传文件，发现信息不够时再自己打开搜索，把外部资料复制回对话框。初稿生成了，他还得比较来源并判断哪些内容值得保留，然后继续下一轮指令。每一轮都在向前，整个任务仍由用户管理

这种体验在模型能力较弱时可以接受。用户本来就把 AI 当成一个会写字、会回答的工具，产品只要降低调用模型的门槛，就能产生清晰价值。现在，模型可以调工具与读取文件，也能根据执行结果改变方向。门槛变了。用户开始关心它能否把事情接着做下去

OpenAI 把深度研究与网页操作合并进 ChatGPT agent，让系统根据任务选择工具并执行动作。Microsoft 把业务应用带进 Copilot 对话，试图连接分析与应用内操作。Google 在 2026 年把 Gemini 的产品方向称为更加 Agent 化，并开始提供主动、持续的帮助。这些产品的实现不同。方向却很接近，生成出来的内容正在被推进为可以完成的工作

一个实用的判断标准，是看用户如何描述完成。如果他只想获得一段翻译或一张图片，这项能力可以在一次输出后结束。如果他希望系统继续读取资料和选择工具，条件变化时还要调整执行，他需要的就是一个完成的结果

一旦价值单位变成结果，产品就得接管从用户目标到交付结果的中间过程。Agent 就是承接这段过程的产品形态

二、Chat 的上限，是用户仍然得充当产品的调度器

Chat 产品最核心的数据是消息。用户发出一条，模型返回一条，当前回合就结束了。这套结构很适合提问与讨论，也适合生成一次内容。它默认每次回答都是一次独立交付

回合结束了，任务没有。一个任务会跨过多次模型调用，中间可能等待用户授权，也会因为外部数据变化而重新规划

某一次回答只是执行过程中的一个事件。它无法单独表示整件事已经完成。任务需要另一套记录方式。聊天记录像一份会议转录，它保留大家说过什么。任务系统更像项目看板，已经完成的内容与正在执行的动作分开保存，阻塞原因和恢复方式也有自己的位置

一个研究任务读取了多份文件，进行到一半时联网搜索失败。此时需要保留的信息，还包括哪些文件已经处理，以及重试会不会破坏现有结果。只保留对话，用户就得自己回看前文，再告诉 AI 应该从哪里继续

产物的归属也会改变。在 Chat 里，一份报告草稿往往藏在某条消息中，它和前面的来源、后面的修订意见分散存放。在任务系统里，报告属于这个任务，系统需要知道它是临时结果还是可交付版本，并保留它与验收要求的关系

很多 Chat 产品解决这个问题的方法，是继续增加功能入口。搜索放一个开关，知识库放一个入口，MCP 和模型选择再分别配置。能力确实变多了，用户也被迫理解产品的内部结构。他还是调度器

Cherry Studio 2.0 开始为 Agent 会话提供独立运行时，执行流可以重连，持久化与工具审批也进入同一套架构。系统因此能够区分任务是在执行，还是正在等待用户授权。失败发生以后，它也有机会从已经保存的状态继续

这些底层改动会直接影响用户是否敢把事情交给 AI。当用户回到任务时，他需要看到现在做到哪里。遇到高风险动作，系统要给出可理解的授权请求。执行失败以后，产品还要说明已经保留了什么，并给出可以继续的动作

Agent 在产品中承担的价值，就是管理这些复杂度。系统内部可以有更多模型和工具。用户面对的决策应该变少。他说清目标，在会改变结果的节点做判断，剩下的调度工作交给产品

三、今年，所有 AI 产品都必须做 Agent 产品

我这里说的所有，指面向最终用户、以 AI 为核心交付的产品。一个 OCR 接口或模型 API 提供的是底层能力。它不在本文讨论的终端产品范围内。终端 AI 产品会接收一个需求，并对用户获得的结果承担产品责任

我坚持所有 AI 产品都要做 Agent，第一个原因是用户的比较标准已经变了。当通用 AI 助手开始搜集资料和操作软件，还能持续执行任务，用户会用能否完成工作来评价一款 AI 产品。一个垂直产品只能回答专业问题，它面对的竞争对手已经包括能够调用专业工具的通用 Agent

第二个原因是单点 AI 能力正在进入 Agent 的工具层。翻译与 OCR 依然有价值，生图和搜索也会继续存在，只是调用入口会向上移动。公司可以专心做一个优秀工具，让其他 Agent 来调用。这时它成了能力供应者，已经不在本文讨论的终端产品范围内。如果它还想直接拥有用户，并理解用户的长期目标，就得向上建立自己的 Agent 层

以生图产品为例。输入提示词并返回一张图，解决的是生成能力。用户正在做的可能是一次活动，他需要符合品牌规范的多个版本，确认以后还要放进正确的素材库。如果生图产品只完成第一步，其他 Agent 就可以调用它，并接管后面的用户关系。入口会跟着任务向上移动

谁拥有 Agent，谁就更接近用户关系。工具通常收到一组参数，然后返回一次结果。Agent 知道用户最终要完成什么，也保留任务过程中的选择与失败。它决定何时调用工具，最后还要检查结果是否达到验收标准。产品和用户的连续交互，会集中到这一层

很多任务使用固定工作流会更稳定。OpenAI 与 Anthropic 的 Agent 构建指南都建议，能用确定规则解决的问题，先使用简单机制。这个限制不会削弱上面的判断。Agent 产品可以在内部调度确定工作流，只把需要判断的环节交给模型。产品承接完整目标，每一步使用多少自主性，由任务风险与结果通过率决定

做 Agent 产品也不要从多 Agent 开始。一个产品可以先用单个 Agent 管理一个目标，只调度当前任务需要的工具，高风险动作交给用户确认。Agent 化要改变的是产品责任，它不要求团队第一天就做出完全自主的复杂系统

这个转型必须从今年开始。今天做出的数据和交互决定，会限制产品明年能承接什么任务。如果现在仍然只保存消息与单次输出，未来增加任务状态、恢复机制和工具权限时，团队就得再次承担 Cherry Studio 正在承担的重构成本。今年还在新做一个 Chat 套壳。等于把产品建在已经过期的价值单位上

继续停留在单次回答的产品，更容易成为别人 Agent 里的一个工具。它依然可以很有价值，只是用户入口和任务上下文都会留在上层 Agent 手里，最终结果也由别人验收

四、Agent 产品不是 Chat 加一个自动执行按钮

一个产品调用了工具，甚至连续调用了很多次模型，也不会自动变成 Agent 产品。判断标准很直接。用户给出一个想要的结果后，产品能否管理中间过程，直到完成、失败或需要用户决定

比如用户让 AI 为一次活动制作海报，系统调用生图模型并返回一张图。如果它不知道品牌规范与交付尺寸，生成失败后也不能继续，这次工具调用仍然只是 Chat 的一次回答。动作执行了，任务还在原地

先看目标。一句用户指令只是起点，产品还要知道什么样的结果算完成。以生成报告为例，系统需要知道交付格式与内容范围，事实标准也要提前确定。没有完成标准，Agent 只会一直行动，却不知道什么时候应该停

接着是上下文和状态。上下文帮模型理解已经发生的事，状态让产品知道当前正在发生什么。一个完整的任务对象需要保存当前步骤与已有产物，必要权限也应该跟着任务。失败时，系统才有明确的恢复点

Agent 还需要工具和行动。它要从真实系统中读取数据，也要在授权范围内产生改变。每个工具都得说清输入与输出，失败时返回可处理的状态。产品还要区分可逆动作与高风险动作。只能生成文字的系统，仍然停留在建议层

这些能力由执行循环连起来。Agent 规划下一步，执行后读取结果，再判断继续还是停下。工具返回的数据与原计划不一致时，它可以调整路径。遇到意图不清或越过权限的问题，它要把决定交回用户

最外层是控制和验收。用户需要看到 Agent 正在做什么，并在会产生真实后果的动作前授权。产品也要支持暂停与恢复，任务结束后还得用事先约定的标准检查结果。用户需要理解计划与风险，也要看得懂结果，不用看到系统内部的每一步思考

Agent 可以只有一个，也可以保留完整界面。它在低风险任务中可以更自主，高风险动作则需要更多人工确认。这些都是产品根据场景选择的自主程度，不会改变 Agent 产品对完整目标负责的核心

最实用的检查方法，是暂时把聊天界面从产品图上拿掉。如果任务仍然有独立目标与状态，失败后能恢复，产物也能按标准验收，这个产品才拥有 Agent 的基本结构

五、Agent 产品应该怎么做

上一节的五层结构，回答的是一个产品必须具备什么，才能承接完整任务。接下来七个方法回答团队应该按什么顺序把它做出来。起点是一件用户已经在现实中完成的事。模型与框架要等到任务定义清楚以后再选，MCP 也只是工具接入方式。下面仍用同一个资料整理与报告交付任务来理解

1. 先定义结果，再定义功能

先别画界面。产品团队先写一张结果卡。它要说清用户提供什么，最后会拿到什么，以及什么条件满足时任务才算完成。这些条件还需要包含不能越过的边界，尤其是只能由用户做的决定

以报告为例，输入可以是一组公司历史资料和调研目标。交付物是一份可编辑文档。重要判断要找到来源，无法确认的内容需要单独标出。这时团队才知道应该提供文件读取与搜索能力，文档生成也有了清楚的要求。如果团队说不清什么算完成，Agent 也无法替用户交付结果

结果卡不要只藏在系统提示词里。任务启动前，用户应该能看到系统对目标与交付物的理解，不能越过的边界也要摆出来。有偏差时可以直接改，成本远低于等 Agent 完整做错以后再重来

2. 把产品的核心对象从会话改成任务

任务需要自己的身份，它要成为一个独立产品对象。目标与当前状态跟着任务保存，已经生成的产物也有固定位置。会话可以继续作为入口，用户输入一个目标后，实际上创建或打开的是一个任务

用户第二天回来，页面首先应该告诉他已经完成哪一部分，现在卡在什么位置。聊天记录可以按需展开，它不应继续承担任务仪表盘的工作。一个任务可以包含多轮对话，后续也能交给其他 Agent 处理。这些交互都应该回到同一个目标和产物空间，避免用户在多份对话历史中自己重建上下文

3. 把功能变成 Agent 可调度的工具

过去的功能入口，要改成 Agent 可调度的工具

文件读取工具负责获取内容，搜索工具返回带来源的结果。文档工具负责保存可编辑产物。每个工具都需要有清楚的输入与输出，失败时也要返回可处理的状态。权限与成本不能藏在工具内部

工具越多，选择越难。当前任务只需要文件、搜索与文档能力，系统就不必同时把生图和数据库写入工具交给模型。按任务阶段逐步暴露工具，可以减少错误选择，权限范围也更容易说清

一个稳定的单 Agent 足以完成第一版。团队先让它正确选择工具，再根据失败数据决定是否增加专用 Agent。架构的复杂度应该由真实问题推动

4. 按风险分配自主权

自主程度要看动作的后果

读取文件和生成草稿通常可以直接执行。它们容易检查，也能重做。当 Agent 要覆盖源文件或发送结果，产生费用的动作也要单独处理。产品需要让用户看清动作对象和可能后果，然后再授权。风险越高，确认越要靠近动作发生的时刻

权限不是一个总开关。它需要同时绑定动作对象与任务阶段。授权一次读取某个资料夹，不代表 Agent 以后都能读取用户的所有文件

授权也不应该变成连续弹窗。用户需要判断 Agent 计划做什么，也要看懂哪一步会产生难以撤销的后果。产品可以在计划层给出概括，只在风险发生变化时再请求用户做新决定

5. 把进度、异常和下一步做成产品反馈

Agent 执行时，用户需要看懂当前进度，不需要阅读完整工具日志。产品可以告诉他正在读取资料，或者正在等待一个会改变报告范围的选择。反馈要解释当前状态对任务意味着什么。模型的内部思考可以留在后台。界面只需要说清已经做了什么，以及对下一步的影响

失败也是产品状态。联网搜索中断时，产品先告诉用户已经处理的资料仍然保留，然后给出重试或更换来源的动作。只显示连接失败，用户还得自己判断任务是否全部作废

6. 为失败、恢复和人工接管设计

任务的每个重要阶段都应该有恢复点。某个工具失败后，Agent 可以在不重复前面工作的情况下重试，也可以更换工具。当剩下的问题依赖业务判断，系统需要整理已知信息与当前分歧，再把这些内容交给用户或专业人员接管

Agent 也需要区分技术缺口和用户偏好。资料格式无法解析，系统应该先尝试其他处理方法。报告应该更看重增长还是风险，只有用户能给出这个选择。会停下来问，和会自己解决问题同样重要

人工接管也需要交接，不能只把整段对话丢给接手人。系统先说清当前目标与已经完成的部分，再整理未解决的分歧。产物的保存位置也要一起交出，让接手的人可以从这个状态继续，不需要重新调查任务历史

7. 用结果通过率验证 Agent

一次成功不算稳定。产品团队需要把真实任务做成评测集，检查交付物是否达到事先约定的标准。结果正确以后，再看整个过程花了多少时间和成本。还要检查哪些人工介入确实改变了结果

每个失败样本都要留下来。有些任务从一开始就理解错了目标，有些失败来自工具或权限。还有一些结果看起来完整，却无法通过验收。这些失败需要不同的产品修改，不能统一归结为模型不够聪明

第一版可以先用能力较强的模型建立通过率基线。团队会逐渐看清 Agent 在哪些环节确实需要推理，然后再把简单分类与固定流程交给更小模型或确定程序。只有当新增的自主性能稳定提高结果通过率，产品才应该继续增加执行步数

这七个方法指向同一个产品原则。系统承担模型与工具的复杂度，也负责保存任务状态。用户保留对目标和关键决定的控制权。产品内部可以越来越复杂，用户完成事情的过程应该越来越简单

Agent 是 AI 产品对结果的承诺

回头再看 Cherry Studio 的这次重构，团队放下已经熟悉的 Chat 结构，转向围绕完整任务组织产品。产品责任也变了。系统不能停在给出一段看起来正确的回答，它还要处理执行中的变化。遇到权限与用户偏好问题时，决定回到用户手里，任务结束后再交付一个可以检查的结果

这也是我坚持今年所有 AI 产品都必须做 Agent 产品的原因。这里的必须有一条清楚边界，产品内部可以继续使用确定工作流，也可以只在少数环节让模型自主判断。架构可以不同，产品承担的责任不能退回一次回答

今年的分界线，是产品是否对完成用户目标负责。首页有没有 Agent 按钮不重要。一个仍把任务拆解与工具调度留给用户的产品，再会说话也只是模型入口。能够接住目标并持续推进，让用户只在关键节点决定，才进入 Agent 产品的设计范围

愿我们永远对世界保持好奇