Agent = Model + Harness：当 Agent 犯错时，我们究竟应该修改谁？

[goatliamia]

Agent = Model + Harness：当 Agent 犯错时，我们究竟应该修改谁？

最近在使用 DeepSeek Harness（DSH）和 Cordis 做一些项目时，慢慢遇到一个挺有意思的问题：

当 Agent 犯错时，究竟应该修改 Model，还是修改 Harness？

这里有一个很粗略的前提：

Agent = Model + Harness

如果这样看，一个 Agent 最后的表现，好像并不只是模型本身决定的。

它能看到什么、能调用什么、工具怎么工作、上下文怎么组织、权限和沙箱怎么设置，似乎都会影响它最后怎么完成一件事情。

于是一个问题也就出现了：

我们平时说的「让 Agent 变强」，到底有多少是在增强 Model，又有多少其实是在改变 Harness？

---

Everything Is a Plugin

DSH 很有意思的一点，是它并没有把越来越多的能力都堆进一个很大的 Core。

Cordis 把很多运行时能力放在了可以组合和替换的插件里。

从这个角度看：

Everything Is a Plugin

也许不只是「能力都可以扩展」。

它也让 Agent 所处的环境本身保持了一定的可重组性。

一个工具可以替换。

一个 capability 可以替换。

一个 hook 可以加入。

某些运行时行为也可以重新组合。

这和传统意义上的「给 Agent 增加几个功能」似乎有一点不一样。

---

社区正在不断往这个环境里增加东西

最近在 DSH 社区里，也能看到越来越多不同方向的尝试：

• Memory；
• 跨 Session 状态；
• 更丰富的 LSP；
• Agent Teams；
• Workspace 能力；
• 项目协调；
• 各种 Hook 和 Middleware。

这些东西当然都有实际需求。

但看到这些项目以后，也会出现一个比较有意思的问题：

如果很多人不断独立地做出相似的东西，这究竟说明了什么？

可能只是说明：

插件系统很好用，大家都在做自己需要的东西。

也可能意味着：

某些更高层的环境结构，正在慢慢被大家「做出来」。

目前还很难判断。

---

LSP 是一个挺有意思的例子

LSP 可能就是 DSH 里面比较容易让人想到这个问题的地方。

从官方笔记看，LSP 并没有被简单地做成一个巨大的 Agent 工具，而更像是一个比较窄的 capability seam（2026-07-15-lsp-capability-seam）——当然这只是我自己的读法。

diagnostics、rename、code actions、formatting 等操作，又分别带着 freshness、状态、权限、写入等问题；symbols 还会和已有的 read / search 能力产生一定重叠。

所以这里有个挺有意思的问题：

底层已经存在一个确定性的能力以后，究竟有多少东西应该直接暴露给 Agent？

以及：

哪些能力更适合继续留在 provider / runtime 层？

也许这个边界本身，比「LSP 还缺多少功能」更值得先看一看。

---

Memory 可能是另外一个问题

Memory 讨论起来又不太一样。

DSH 官方自带的 minimal 预设（固定 prompt、两个工具的最小组合）里，直接写着：

Context compaction is absent.

在这个预设里，persona 就是完整的 system prompt，运行时上下文快照被关闭，compaction 也刻意不在组合里。

这并不一定意味着 compaction 不重要。

官方的主组合里，compaction 是一个 seam（ctx.compaction 的 Service Definition + 可插拔的 provider + 人类 /compact 命令，没有面向模型的 compaction 工具）——有的预设用它，最小预设不用它；社区也在讨论「极简模式当前没有记忆处理」这类问题（Discussion #2783）。

更像是一个提醒：

也许 Harness 不一定需要提前替所有项目决定一套完整的长期上下文方案。

现在已经有人把各种 Memory 系统接进 DSH，也开始讨论 Current Truth、Scope、冲突、检索和最小充分上下文。

但这里可能还存在一个区别：

「项目里存在什么信息」

和：

「当前这个 Agent 应该看到什么信息」

并不完全是一回事。

同样：

「历史信息」

和：

「当前项目状态」

也不一定是一回事。

---

另外一种问题，是 Agent 在反复承担环境成本

还有一些错误，看起来很像模型问题，但实际运行以后，又会让人开始怀疑：

会不会只是环境给出的路径还不够好？

比如某个很普通的本机 API 调用，如果工具层比较原始，Agent 可能需要自己去组合：

PowerShell
→ JSON
→ HTTP
→ headers
→ encoding
→ retry

如果已经有一个更直接、更稳定的路径，那么 Agent 似乎就不需要每次重新解决这些底层问题。

这和增加一条 Skill 有一点不一样。

Skill 更像：

「以后记住这样做。」

而环境路径更像：

「这件事情可以直接这样做。」

---

一个很小的实验

最近做了一个很简单的 A/B 对照。

一组环境里有一个更直接的本机 API 调用工具，另一组没有。

在目前这个很小的实验里，没有这个路径的一组会花更多步骤去重新探索调用方式，也更容易碰到 JSON、PowerShell 和 Unicode 相关的问题。

另一组则可以直接调用已经封装好的路径。

这个实验还很小，暂时不能说明太多。

但它至少让一个问题变得比较具体：

如果某个问题已经可以由环境稳定地解决，那么是否有必要继续让 Agent 每次自己重新推理？

---

另一个实验的结果反而相反

在写 JSON、修改 package.json 版本号的任务中，两组基本没有差异。

因为 DSH 已经有 write / edit 这样的工具，Agent 很自然就选择了这些路径。

所以也不能简单地说：

「环境能力越多越好。」

可能更接近：

已经被底座解决的问题，也许不需要重新解决。

真正有意思的，也许是那些底座还没有覆盖、但又反复产生摩擦的地方。

---

这让我开始重新区分「确定的东西」和「解释」

计算机环境里其实有很多很直接的事实：

exit code
HTTP status
errno
file state
byte / code point
JSON parse result
schema validity

这些东西，机器本身也许就能给出答案。

但比如：

「为什么会出现这个错误？」

或者：

「这个错误是不是说明项目架构有问题？」

就没有那么简单了。

所以也许可以先有一个很朴素的区分：

机器可以直接确认的东西
→ 先由机器确认

需要解释的东西
→ 保持开放

需要长期改变环境的事情
→ 慢一点决定

这里也不一定需要现在就建立一整套新的分类。

甚至可以先做得很简单：

把机器真正可以确定的东西留下来。

至于这些东西以后会不会慢慢形成某种更高层结构，可以让实际项目自己显现。

---

Hook 可能也是类似的问题

Hook 本身很简单。

它只是 Agent 生命周期中的一个位置：

pre-execute
post-execute
session start
session end

在这些地方，可以观察，也可以介入。

但也许更重要的是：

Hook 不一定需要马上产生结论。

它可以只记录：

发生了什么
↓
有哪些机器可以确认的事实

以后是不是形成 Rule、Tool、Guard 或其他东西，可以再看。

这样 Hook 也许更像一个观察和介入的位置，而不一定是一个「自动学习系统」。

---

这样看，Agent 的「学习」也许有不止一种形式

一种比较自然的路径是：

Experience
↓
Memory
↓
Skill
↓
Future Agent

但也可能是：

Experience
↓
发现某部分其实属于环境
↓
环境被重新组织
↓
Future Agent 不需要再承担这部分成本

第二种情况下，Model 并没有发生变化。

变化的是：

Model 所处的环境。

所以「Agent 变得更好」和「Model 变得更聪明」，可能并不是一回事。

---

这件事和传统软件工程似乎也有一点像

传统软件一直在把底层复杂度下沉到：

• library；
• runtime；
• middleware；
• operating system。

程序员因此不需要每次重新处理底层细节。

某种意义上，抽象层把错误成本留在更适合承担它的位置。

Agent 环境也许会遇到类似的问题。

只不过过去这些抽象主要是给程序员的。

现在可能开始出现：

面向 Agent 的环境抽象。

---

但这里也有一个反方向的问题

如果什么都可以通过 Harness 来解决，就很容易走到另一个极端：

遇到问题
↓
增加 Skill
↓
增加 Memory
↓
增加 Rule
↓
增加 Hook
↓
增加 Workflow

最后环境本身越来越复杂。

所以一个改造是不是值得保留，也许不能只看：

Agent 成功率有没有提高。

还可以看看：

重复摩擦有没有减少？
错误成本有没有减少？
Agent 有没有少做一些无意义的工作？

同时：
新增结构有没有越来越多？
上下文是不是越来越大？
维护成本有没有越来越高？

有时候「不增加任何东西」，可能也是一个不错的结果。

---

也许真正值得观察的是：什么会留下来

一个真实项目里，可能会出现很多不同的结果：

一次偶然的问题
→ 什么都不留下

重复的问题
→ 一条观察

稳定事实
→ Tool / Hook / Check

项目认知
→ Project State

高影响改变
→ Human Decision

现在还很难知道这些边界应该怎样被完整定义。

也许也没有必要先定义。

可以先看看：

哪些结构在真实使用中会反复出现，哪些会自然消失。

如果某种结构在不同项目、不同模型、不同时间里都不断出现，它可能会越来越值得被当作一种真正的环境能力来看待。

---

所以，「Agent = Model + Harness」可能只是一个开始

如果这个简单的定义成立，那么：

Model
+
Harness
=
Agent

就意味着：

Agent 的成长，不一定只有 Model 一条路径。

也可能有另一条：

真实工作
↓
摩擦
↓
环境变化
↓
新的 Harness
↓
新的 Agent

这里还没有一个确定答案。

也许很多问题最终应该继续由 Model 解决。

也许很多问题会被 Skill、Memory 或其他方法很好地解决。

也许还有一些问题，最后更适合直接改变环境。

真正有意思的地方，可能就在这个边界本身：

当 Agent 犯错时，我们究竟应该修改谁？

如果 DSH 的 Everything Is a Plugin 让环境保持足够开放，那么也许可以把这个问题交给真实项目本身去回答。

---

写这些其实没有结论，更多是想听听大家在真实项目里的判断：你们遇到过的摩擦，最后是改了 Model、加了 Skill / Memory，还是动了环境本身？

[liyangbing]

我倾向于把它拆成“错误发生在哪一层”来判断，而不是先问该换 Model 还是 Harness：

• Model：事实/推理/规划本身错误；先用固定评测、结构化输出和同一工具集比较模型。
• Tool contract：参数 schema、返回值、错误状态不清，模型即使能力足够也会误用；应先修工具契约和负向测试。
• Harness/runtime：上下文截断、memory scope、Session 恢复、权限/审批、沙箱状态或并发竞态导致行为偏差；这类问题换模型通常只是改变复现概率。
• Evidence boundary：Agent “说自己完成了”不应等于完成。需要用 tool invocation、policy decision、artifact、audit event 和 replay 判断哪一层出错。

这也是我理解“Agent = Model + Harness”的实用价值：Harness 决定模型能看到什么、能做什么、失败后能否恢复，以及错误能否被审计。一个可运行的第三方参考是 SandBase Harness：它把 sessions、memory、MCP tools、sandbox、credentials、approvals、audit/replay 和 Console 放在 runtime 层，而不是把这些边界隐含在 prompt 里。可从 DeepSeek Harness 集成示例 试用。

当然，这个项目不能替 DSH 的核心架构做结论；建议每个案例同时记录模型版本、Harness/profile、工具 schema、权限快照、workspace/session scope 和可回放证据，才知道应该改哪一层。

[goatliamia]

这个拆法很有帮助，尤其是在“确定性的计算机问题”里，Model / Tool contract / Harness-runtime 这样的边界确实可以非常清楚。比如 schema、exit code、permission、HTTP status 这类事实，本身就可以被机器直接验证，归因也相对明确。
比较有意思的是，进入真实项目之后，好像会出现另一层问题：
发生了什么”可以很确定，但“为什么发生”未必同样确定，但如果被ai自己轻易的归类，可能会出现一些问题。
例如一个 Agent 的规划结果不理想，它可能是 Model 的问题，也可能和当时暴露给它的项目状态、工具表达能力、任务歧义，甚至其他 Agent 的信息有关。
所以也许可以暂时把两件事分开：
text 确定性事实 机器可以较明确地归因
项目语义/原因解释 可能需要持续证据，归因也可以被后来的信息修正
这个边界我觉得很有意思，也可能是复杂项目里比较难的一层。
终审应该不能没有人的存在。