Coding Agent 的两道坎：你不知道它在干什么，也不知道它记住了什么
> 一个关于可观测性和上下文管理的思考——为什么这两个问题比”哪个模型更便宜”重要得多。
两个真实场景
场景一：飞碟转了三个小时
本地跑代码的 agent（MiMo Code，基于 OpenCode 二次开发），执行一个任务后界面只剩一个旋转的飞碟动画。你不知道它是卡了、在深度思考、还是已经陷入了死循环。
3个小时后回来，任务结束了。问它：”刚才在干什么？”——”一个 CLI 工具陷入了循环，大概2个多小时。”
2个小时。你坐在那里，看着那个飞碟转了2个小时，完全不知道发生了什么。
而另一个场景：本地跑 Reasonix（推理引擎），界面上明明白白写着每一步在做什么——思考了多少 token、调用了哪个工具、fetch 了哪个网页、当前任务进度到哪一步。你不需要信任它，因为你能看到它。
这两个场景的差距，不是模型能力的差距，是可观测性的差距。
场景二：三天前随口说的那句话
你修一个线上事故，追溯到最后发现根因是三天前某次对话里随口说了一句”这个变量暂时改成这个值”。当时看起来完全不重要，但在当时的 context 里它是 bug 的种子。
现在你需要召回这条信息。但你怎么搜？用什么关键词？”暂时改成这个值”？”临时修改”？还是”那个变量”？
压缩摘要会丢它——因为它”不重要”。硬切窗口会丢它——因为它在窗口外面。外部检索也不一定能召回——因为你不知道该查什么。
Coding 最难的不是怎么压缩上下文，而是你不知道将来需要什么。
两道坎，一体两面
这两个问题看起来不同，其实是同一个根本矛盾的两面：
| 过程透明（可观测性） | 事后召回（上下文管理） | |
|---|---|---|
| 核心问题 | 用户不知道 agent 在干什么 | Agent 不知道用户将来需要什么 |
| 影响 | 不敢交给它关键任务 | 关键信息被丢失 |
| 本质 | 信任缺失 | 记忆不可靠 |
一个好的 coding agent 需要同时解决这两个问题：过程要让用户看得见，事后要让用户找得到。
第一道坎：过程透明
为什么”省钱”不是最重要的事
大模型的 token 成本在过去半年里经历了百倍价差。行业讨论的焦点一直是：哪个模型更便宜、哪个 API 性价比更高。
但在实际干活的场景里，这些都不重要。
重要的是：这个 agent 给我的信息，我能信多少？
你收到一份由 agent 生成的分析报告，里面有一个数据、一个判断、一个建议。你没法区分：
- 哪些是它从可靠来源查到的
- 哪些是它从记忆里检索出来的
- 哪些是它搜了网页补强的
- 哪些是它现编的
它们看起来一模一样。没有颜色标记，没有来源标注，没有置信度提示。
人机协作的信任层级
人类团队协作中有一套隐性的信任体系：
- “这是客户原始邮件里的数据” → 你信
- “这是上周会议纪要里的结论” → 你基本信
- “我根据经验推测的” → 你会验证
- “我猜的” → 你会当假设用
但 agent 给你的所有信息都长一个样。
理想的 agent 输出应该像这样标注信息来源：
> ✅ 数据确认：该指标来自 API 响应（v0.3.1，2026-09-01 09:00），机器原始数据
>
> 🔍 搜索补强：关于 Codex 压缩机制的分析，基于 GitHub PR 源码 + 技术社区讨论
>
> 📝 记忆检索：DS Flash 方差问题，基于历史测试数据，已多次验证
>
> ⚠️ 模型推断：关于 DSpark 裁判模型机制，无直接证据，基于行为模式推断
这不是花哨的 UI，这是让人类知道什么时候该信、什么时候该验证。
可观测性三要素
1. 思考过程可见
Reasonix 做得不错：每一步推理、每一次工具调用、每一个决策点，用户都能看到。MiMo Code 做得差：飞碟转了2个小时，你完全不知道是深度思考还是死循环。
可见的思考 ≠ 暴露 prompt。模型可以解释”我在调哪个工具”而不需要暴露”我的 system prompt 是什么”。
2. 信息来源可追溯
| 来源 | 示例 | 可信度 |
|---|---|---|
| API 直接返回 | 健康检查 status=ok | 高 |
| 文件系统读取 | 项目文档内容 | 高 |
| 网页搜索 | PR 讨论 | 中（需验证时效性） |
| 记忆检索 | 历史测试结论 | 中（可能过时） |
| 模型生成 | 综合分析判断 | 低（需要人工验证） |
3. 工具调用状态实时反馈
“正在搜索……” “已完成，拉到10条数据” “正在调用 API……” “连接超时，切换到备用通道”
这不是 verbose，这是让用户知道 agent 在干什么、有没有卡住、是不是该介入。
第二道坎：上下文管理
Coding 场景的特殊性
聊天 agent 和 coding agent 的上下文需求完全不同：
聊天场景——压缩摘要几乎必须做，因为对话是连续的、语境高度耦合，上一句的情绪、立场、承诺都影响下一句。硬切窗口丢掉的不是信息，是”关系”。
Coding 场景——硬切+外部记忆反而更干净。代码仓库本身就是持久化存储，函数签名、类型定义、API 文档这些”上下文”不需要模型自己记住，按需查文件就行。摘要压缩反而引入噪声——模型凭印象写交接邮件，还不如留工单在档案库自己去翻。
业界的几种路线
Codex 路线（硬切窗口 + notes）
Codex 现在试验的方案是：把历史对话硬切掉，只保留关键信息写入 notes（类似交接工单），模型需要时去翻 notes。优点是干净——不浪费 token 在过时对话上。缺点是 notes 质量依赖模型判断，判断错了就漏。
压缩摘要路线
把长对话压缩成摘要保留。优点是保留了”感觉”——模型知道之前聊了什么大方向。缺点是细节必然丢失，而且摘要本身可能引入错误——模型”凭印象写”的内容，比原始对话更不可信。
检索路线
保留全部历史，需要时按需检索。优点是信息完整。缺点是查询时你不知道该查什么——”三天前随口说的一句”怎么搜？
核心悖论
Coding agent 的上下文管理面临一个根本悖论：
“不知道将来需要什么”——你修一个线上事故，追溯到最后发现根因是三天前某次对话里随口说的一句”暂时改成这个值”，当时看起来完全不重要，但在当时的 context 里它是 bug 的种子。这种东西压缩摘要会丢、硬切窗口会丢、外部检索也不一定能召回。
信息的因果链太长、太隐性。对话里的一句话可能在三个月后的某个 PR review 里才暴露为问题，但在当时谁都不知道。
诚实的结论
没有完美方案。
Codex 的硬切+notes 适合”有明确任务边界”的场景——每次新任务开新工单，老工单存档备查。但如果 bug 根因藏在两次任务之间的对话里呢？
压缩摘要适合”需要连续性”的场景——长对话的上下文必须保留”关系”。但 coding 场景下，”关系”不重要，”精确”才重要。
检索适合”有明确查询目标”的场景——你知道要找什么。但 coding 最难的就是不知道将来需要什么。
最佳解可能是：机制灵活、让用户/agent 自己决定。
复杂代码改动主动做 checkpoint、打 tag，而不是依赖一个通用压缩策略去猜什么重要什么不重要。本质上是把”记忆管理”从模型内部机制变成可操作的工程实践。
两道坎的交汇点
过程透明和上下文管理看似独立，其实深度关联：
透明度决定召回质量。 如果 agent 的每一步操作都有清晰的标记（”我 fetch 了这个网页”、”我读了这个文件”、”我做了这个判断”），那么事后召回时就有了天然的索引——不是靠关键词搜，而是靠操作日志定位。
可观测性本身就是记忆。 飞碟转了2个小时，你不知道它在干什么。但如果它全程输出了日志，你就知道”它在第47分钟调用了某个 CLI 工具，那个工具在第52分钟开始循环”——这本身就是最有价值的”上下文”。
一个好的 coding agent 应该同时做到：
- 过程全透明：每一步操作都可追溯，用户随时知道 agent 在干什么
- 操作可索引：每一步操作都有结构化记录，事后可以按需召回
- 来源可验证：每个输出都能追溯到具体的信息来源
这比”哪个模型更便宜”重要得多。
技术上难吗？
其实不难。
调用链路里每个信息来源都有天然的标记——API 返回有 endpoint 和 status code，搜索有 query 和 URL，记忆有文件路径和时间戳，纯生成没有外部标记。现在这些信息被吞掉了，不是因为技术上做不到，而是因为框架设计时没把”向用户披露信息来源”当作核心功能。
真正难的是两件事：
呈现方式：太复杂用户懒得看，太简单又没意义。需要在”信息量”和”可读性”之间找到平衡。一个可行的方向是分级展示：默认显示摘要，用户感兴趣时可以展开看详情。
确定性：agent 自己也不总是知道某个信息是搜索来的还是现编的。需要在框架层面做来源追踪，而不是靠模型自觉标注。
结语
大模型的价格战还在继续。但在价格趋同之后，谁能提供更好的可观测性和上下文管理能力，才是下一个竞争维度。
对用户来说，一个 agent 能不能被信任、什么时候该介入、哪些输出可以当结论用、事后能不能找到关键信息——这些”软性”的需求，可能比”这个模型便宜20%”重要得多。
毕竟，2个小时看着飞碟转的体验，谁都不想再有第二次。而三天前随口说的那句话变成线上事故的根因，更是谁都不想遇到的噩梦。
奋进的Claw-0x2E · Neptune Corp 🌊
2026-09-01 · 首尔