未来Agent 的发展方向有两个，我们用 dense/sparse 来区分。 目前大家看到的所有agent 都是 dense 的。今天重点也是dense agent 后续的发展方向：从过程，会话管理到 结果管理。
我们在我们的 Agent 客户端里做了一个“交付汇报”页，把不同项目的工作集中起来，列出哪些需要用户处理，哪些刚刚结束，哪些还在进行。客户端里还有一个聊天面板， Agent 可以在回答中生成会话卡片，用户点击卡片，就能进入对应项目的工作会话。
这两项设计要解决的是一个很实际的问题：用户已经把工作交给了 Agent ，后面还得找得到这件工作，看得懂它的结果，并且方便地继续处理。 Agent 执行了多少步骤，与用户管理这些工作要花多少时间，是两件需要同时考虑的事。
只让 Agent 做一件事时，聊天窗口通常够用。用户交代要求，等它执行，再看回复或打开附件。整个过程都在眼前，很少需要专门查找。
同时做几件事，情况就不同了。假设一边让 Agent 写文章，一边改代码，另一边在远端打包。用户离开一会儿再回来，可能有一项已经完成，一项还在运行，还有一项停下来等他登录。此时，用户需要先弄清楚这些工作各自怎么样了。
如果面前只有一列会话标题，他就要逐个打开，找到最近的回复，再判断需不需要自己处理。有的会话昨天已经看过，有的今天新增了结果，有的标题和最初的任务已经不太一样。程序可以同时执行，用户的查找和阅读却要一件一件来。工作越多，这部分时间就越不能忽略。
因此，我们先把需要用户看的内容集中到了交付汇报里。用户回来以后，可以先看“等你处理”，再看“刚完成但未查看”和“正在进行”。下面这张 9 月的截图，就把三个项目里正在进行的工作列在了一起。
这个页面帮助用户决定先看哪件事。如果工作在正常进行，他可以暂时不管；如果有新的成果，可以打开查看；如果卡在一个只有自己能解决的问题上，就先补上这个条件。用户不必先了解每个项目里最近说了什么，才能决定把时间花在哪里。
这里的说明还必须具体。以一次远程打包任务为例，用户要的是一个分享链接， Agent 查到缺少登录凭据，暂时不能上传。汇报需要告诉用户该去哪里登录，登录后才能继续哪一步。只写“需要你处理”，用户还是得进入会话寻找原因。
不过，汇报解决不了所有查找问题。用户有时并不关心眼下全部工作的进度，只想找回某一件事。他记得以前问过一个问题，却未必记得会话标题，也未必记得当时是在哪个项目里问的。此外，用户还想知道自己在多设备里的关注点是什么（相当于一个全局视图）。
聊天面板可以承接这种需求。用户直接描述自己记得的内容，由 Agent 查找相关会话，并把找到的入口放进回答。下面这张截图里，让系统查看下我最近关注的是哪些，核心会话也会变成可点击的卡片出现。
卡片上写着会话的名称、所在项目和相关活动信息，用户可以先判断是不是自己要找的那一条。确认后，直接点击会话卡片，就能进入原来的会话。用户不用先记下项目名称，退出聊天，再去项目列表里重新找一遍。
回答因此多了一层用途：它可以把用户带到接下来要操作的地方。解释负责帮助人理解情况，卡片负责打开相关工作。对于用户来说，查找与进入会话是接着完成的，中间省掉了一次手工定位。
这样看，交付汇报和聊天面板分别适合两种使用情形。用户刚回来，想知道最近有哪些事情需要自己看，交付汇报更方便。用户已经想起一件具体的事，想找到它在哪里，就可以直接问聊天面板。两种入口都应当让用户方便地进入相关会话。
会话详情则保留这件工作的具体内容。原来的要求、中间的修改、 Agent 的说明和后续指令，都需要在这里找到。下图中的会话页保留了“返回交付”，让用户处理完一件事后，能够回到汇报继续看其他工作。
图： 9 月的会话详情页，上方有“返回交付”和结果说明，下方保留原始指令及执行状态。
这些页面之间的联系很重要。用户可能先从汇报里看到一项工作，再进入会话补充要求；也可能通过聊天找到旧会话，打开后继续讨论。产品需要让他顺着已经找到的内容往下做，减少在不同列表之间来回寻找的次数。
因此，在这样的设计里，聊天可以成为管理会话和结果的入口。用户用自然语言描述要找什么， Agent 帮他查找和解释，再提供能进入具体工作的卡片。只要这些入口连接得准确，聊天本身就能帮助用户管理工作。
不过，入口方便以后，还有一个问题必须处理好：同一项工作经过几次对话和执行，用户能不能看清现在的结果。
拿改文章来说，用户先让 Agent 写初稿，第二天又提出修改，最后要求导出 PDF 。这仍然是在处理同一篇文章。再次打开时，用户需要知道当前哪一版可以用，哪一版还在修改，导出的文件对应哪一份正文。会话卡片能帮助他回到原来的工作，成果与版本之间的关系也需要保留清楚。
完成状态同样如此。 9 月那项远程打包任务，因为缺少登录条件进入了“等你处理”，卡片下方却同时显示“已完成”。这一轮排查确实结束了，用户要的分享链接还没有生成。如果界面只告诉他程序结束了，就仍然需要他自己判断工作是否做完。
对于这种情况，产品应当把已有进展、缺少的条件和下一步分开说明。用户完成登录以后，后续执行应该接着生成链接。只有约定的产物已经交出，相关检查也有了结果，才有依据改变这项工作的完成状态。查看过一张卡片，或者不再关注它，都不能代替这个判断。
这也是结果导向需要继续做下去的地方。眼下的交付汇报把分散的信息集中起来，可导航的聊天回答缩短了查找路径。在这些功能之上，还需要逐步把一项工作的要求、当前成果和未完成的部分保存清楚，让后续修改能够接上。界面方便查找，记录能够说明现状，两方面都需要做好。
当然，用户刚开始讨论一个想法时，可能还没有明确的交付要求。这时可以先聊，等讨论形成具体工作，再持续跟进。没有必要让每一次提问都先变成一张需要填写完整的任务表。
我更愿意用一些直接的问题检查这套设计：找一段旧会话，要经过多少次跳转；判断一件事有没有完成，要读多少无关内容；看到一个需要处理的问题，能不能顺着页面把它处理下去。这些地方省下的时间，才是用户能感受到的便利。
我认为， Agent 产品需要把执行工作和管理工作一起考虑。让 Agent 同时多做几件事，也要让用户更容易找到这些事、看清结果、继续跟进。用户花在寻找和核对上的时间降下来了， Agent 增加的执行能力才更容易用得上。