最近使用各种 Agent 产品，我发现一个挺反直觉的现象：
对话越来越长，不代表 Agent 掌握的有效上下文越来越多。
比如，让 Agent 修改一份 PPT。第一轮调整结构，第二轮修改文字，第三轮又推翻其中两页。聊到后面，对话里同时存在初稿、修改稿和已经被放弃的方案。
Agent 要想继续工作，必须从一长串历史记录里判断哪些要求仍然有效，再尝试还原 PPT 现在的样子。
说实话，这个过程效率并不高。
因为对话更像一份不断增长的过程日志，其中包含需求、解释、尝试、失败和反馈，有效信息的密度会越来越低。
产物则不同。
无论前面修改了多少轮，当前这份 PPT 已经包含最终保留下来的页面顺序、文字内容和元素位置。
对话是线性增长的过程日志，产物是不断收敛的当前状态。
对话适合追溯过程，产物更适合继续工作。
AI Coding 为什么更容易跑通闭环
顺着这个思路，我又想到一个问题：
为什么现在的 Coding Agent，整体效果往往比 PPT、表格等 Agent 更稳定？
模型的代码能力当然重要，但可能还有一个经常被忽略的原因：
代码是一种非常适合 Agent 读取的产物。
代码本身就是文本，结构清晰，可以搜索、比较和局部修改。项目当前是什么状态，Agent 重新读取代码仓库就能知道，不需要完全依赖聊天记录。
修改之后，还可以通过 Git Diff 查看变化，通过编译、测试和运行结果完成验证。
所以，即使前面的对话很长，甚至丢失了一部分上下文，Agent 仍然可以重新读取项目，快速回到真实工作现场。
而 PPT、Word、表格、架构图和 3D 模型就麻烦得多。
Agent 不仅要读取文件，还要理解页面结构、视觉关系、公式关联或者空间状态。修改以后，又要通过对应的运行环境重新渲染和验证。
很多时候，问题不只是模型能力不够，而是产物还没有形成一套成熟的"读取---修改---展示---验证"机制。
当产物成为主要上下文
这也让我开始重新思考：Agent 的上下文究竟应该围绕什么来组织？
今天大多数 Agent 产品仍然以对话为中心。用户通过对话提出需求、反馈问题，Agent 也主要依靠历史消息理解任务进度。
但如果当前产物比历史对话更准确、更高效地保存了工作状态，那么它就不应该只作为对话结束后的附件，而应该成为下一轮工作的主要上下文。
这就是我理解的"以产物为中心"。
它并不是不要对话，而是重新划分两者的职责：
对话负责表达目标、补充要求和解释判断，产物负责保存当前真实状态。
对应的 Agent Loop 也会发生变化。
Agent 每一轮都先读取当前产物，再结合用户本轮提出的增量要求完成修改，通过对应的运行环境进行验证，最后把更新后的产物交给下一轮。
代码交给代码仓库和测试系统，网页交给浏览器，PPT 交给幻灯片结构和渲染环境，表格则保留单元格、公式和计算结果。
Harness 需要统一的，是人的意图、产物版本、修改操作和验证结果之间的关系，而不是把所有产物强行转换成同一种格式。
这样，Agent 每一轮拿到的就不再是不断膨胀的历史描述，而是最接近当前事实的工作状态。
我感觉，未来 Agent 产品之间的差距，可能不只在于能记住多长的对话，更在于能否真正理解和操作不同类型的产物。