Harness Intelligence: Compiling Repeated Reasoning into Runtime Reflexes

[creatureyuan]

TL;DR: A cat does not send every stimulus to the cortex and reason about it from scratch. Some reactions are handled by lower-level reflex circuits, while repeated behaviors can become increasingly automatic. I wonder whether agent systems could evolve in a similar direction: let frontier models handle novel reasoning, while the harness gradually learns to turn repeated patterns of reasoning into cheaper, auditable skills, policies, verifiers, and eventually runtime “reflexes.”

I've been thinking about a possible direction for agent harnesses that I would tentatively call Harness Intelligence.

The basic question is:

Should all agent intelligence eventually live inside the model, or could part of it be learned and accumulated by the harness itself?

The biological analogy

Biological intelligence is not implemented as "send every stimulus to the cortex and reason about it from scratch."

Some behaviors are handled by reflex circuits, while other learned and automatic behaviors rely on systems such as the cerebellum and basal ganglia. Expensive deliberation is reserved for situations that actually require it.

Current LLM agents often work in almost the opposite way:

event
→ put it into context
→ call frontier model
→ reason
→ choose action
→ receive result
→ call frontier model again

Even relatively repetitive decisions may require another expensive model inference.

I wonder whether a mature harness could gradually compile repeated reasoning into cheaper runtime behavior.

A possible learning loop

Imagine an agent repeatedly performs a task:

Model reasoning
→ action
→ outcome
→ trajectory / failure signal

The system could periodically analyze these trajectories and discover recurring patterns.

For example:

• Large refactors repeatedly forget database migrations.
• A certain class of TypeScript errors always requires the same diagnostic files.
• A provider/model combination repeatedly fails under a particular context pattern.
• Certain tool failures almost always lead to the same recovery sequence.
• Context pressure repeatedly causes the model to forget a specific verification step.

Instead of making the frontier model rediscover the solution every time, the system could generate a candidate:

policy
skill
verifier
router
context strategy
tool
runtime rule

Then:

candidate behavior
→ replay / sandbox evaluation
→ compare against previous trajectories
→ promote if consistently useful
→ retain provenance + rollback

The model weights have not changed, but the agent system has genuinely learned from experience.

Thinking → skill → reflex

This suggests an interesting hierarchy:

Frontier Model
abstract reasoning / planning / novel problems
        ↓
Learned Harness
routing / habits / verification / context policies
        ↓
Reflex Runtime
retry / caching / interrupts / permissions / deterministic reactions

Something might initially require substantial model reasoning.

After being solved many times, it could become a reusable skill.

After becoming extremely predictable, part of that skill might become almost reflexive runtime behavior.

In other words:

reasoning → skill → reflex

This resembles how humans gradually turn effortful actions into automatic ones.

Two destinations for experience

It may also be useful to separate two kinds of learning:

                    Experience
                    /        \
                   /          \
          procedural           generalizable
            patterns             knowledge
               ↓                    ↓
       Harness learning        Model learning
               ↓                    ↓
    skills / policies /       training / RL /
    verifiers / routing        future model

Some experience probably deserves to be distilled back into the model.

But some experience may be better represented outside the weights as an inspectable, reversible, environment-specific behavior.

This could provide a much faster form of continual learning than waiting for the next model training cycle.

Why this seems relevant to Harness

A harness already sits at the boundary between the model and the environment. It can observe:

• model calls
• tool calls and results
• session trajectories
• failures and retries
• environment state
• verification results
• user corrections

That makes it a natural place to experiment with this kind of procedural learning.

The important part, in my view, would be to keep it auditable rather than silently self-modifying:

• every learned behavior should have provenance;
• candidate policies should be evaluated before promotion;
• behaviors should be reversible;
• local optimizations should not silently become universal rules;
• the system needs protection against reward hacking and accidental overfitting.

Questions for the DSH team/community

I'm curious whether this direction overlaps with how you think about the future of Harness:

1. Could adaptive or learned harness behavior be an interesting long-term direction for DSH?
2. Should repeated successful/failure trajectories be able to produce candidate skills, policies, or verifiers?
3. Would the plugin architecture be a natural experimental boundary for this, instead of allowing the core harness to freely self-modify?
4. In a future continual-learning agent, how should we decide which experience belongs in the model and which belongs in the harness?

My broader intuition is that future agent intelligence may not be concentrated entirely in model weights.

The model may remain the core general reasoning engine, while the harness gradually accumulates something closer to procedural intelligence — learning when to think, when not to think, what to retrieve, what to verify, and which repeated reasoning can safely become a reflex.

Would love to hear how others think about this.

[denial123789]

A useful boundary here may be to treat “learning” as an artifact promotion pipeline, rather than allowing the live runtime to rewrite itself:

trajectory set
  -> candidate Skill + verifier
  -> offline replay on the source cases
  -> holdout / counterexample replay
  -> shadow mode
  -> scoped promotion
  -> rollback on verifier or policy regression

The important distinction is between three artifact classes:

1. Skill: still asks a model to reason, but supplies a reusable procedure, budget, stop condition, and output contract.
2. Verifier/policy: deterministic code checks observable properties of the result or action before it is accepted.
3. Reflex: deterministic runtime behavior for a narrow condition, such as retry classification, cancellation, caching, or mandatory preflight checks.

I would avoid promoting a Skill directly to a reflex. A safer path is Skill → measurable output contract → verifier → shadowed policy → reflex. The model-generated explanation is not the training signal; the durable signal is the tuple of inputs, observable actions, verifier results, user correction, and environment version.

Some promotion gates that seem important:

• immutable provenance: source trajectories, candidate version, generator model, and evaluator version;
• scope keys: repository/workspace, tool schema, provider/model family, OS, and runtime version;
• negative examples and counterfactual replay, not only successful trajectories;
• permission monotonicity: a learned artifact cannot grant more authority than its parent policy;
• explicit abstention and a fallback to deliberation when its preconditions do not match;
• promotion thresholds based on held-out outcomes, not frequency alone;
• reversible rollout with a small blast radius.

A small working example of the first two layers is SandBase's multi-source-search Skill: the Skill defines a finite search budget, independent-source rules, and an evidence-ledger contract; a standard-library offline validator rejects duplicate/unknown evidence, unsupported confidence, and hidden conflicts. It deliberately does not claim the evidence is true. That separation—procedural guidance versus deterministic structural verification—has been useful.

For the harness layer, SandBase Harness keeps sessions, tool events, audit/replay, permission policies, and sandbox execution in one runtime boundary. The part I would add next for this idea is a first-class CandidateBehavior record containing provenance, scope, evaluator suite, rollout state, and rollback target.

I am affiliated with SandBase AI; sharing these links as concrete implementations of the Skill/verifier and runtime/audit layers, not as evidence that this design is settled. The most interesting open question to me is how to construct counterexamples automatically without letting the same model both propose and certify the behavior.

[weijiafu14]

这个方向我觉得值得想，@denial123789 那个"artifact promotion pipeline"的分层（Skill / Verifier-policy / Reflex，且不许 Skill 直升 Reflex）也是我见过对这类提案最有用的约束。

我想补一条来自实际语料的边界条件，它会决定这个学习回路第一步该做什么。

在"把重复的推理编译成反射"之前，先确认那个推理为什么在重复

你举的例子里有一条是：

Certain tool failures almost always lead to the same recovery sequence.

这个假设——"重复出现的推理模式 = 值得固化的经验"——在很多情况下成立。但我最近横着读了这个社区几百个帖子，发现有相当一批"模型反复做同一个决定"的案例，原因不是它学会了一个模式，而是它拿到的输入本身是错的或不完整的：

帖	模型重复做了什么	为什么
#3568	原样重发同一个坏参数 17 次	JSON 解析失败退化成空 {}，server 报"缺少必填参数"，模型据此以为是自己没传
#3489	重新规划 61 次，500 多秒	MCP 会话过期被当成普通工具错误，而这个错误无论怎么规划都不会变
#2690	连续几十轮跑同一个 no-op	技能文档说"注册的工具下一步就能调"，而实际条件是"下一次装配"——模型完全按文档行事
#1421	中断了两个健康的子代理	它没有墙钟，只能数轮次；2 分钟里攒出 9 个空转轮被当成"等了很久"

这四条都是高度可复现的模式，而且都会被轨迹分析捕捉到。 但它们没有一条该被编译成反射——把它们固化，等于把当时那个错误的输入一起固化进去了。

以 #3568 为例：一个从那批轨迹里学出来的"反射"，很可能是"遇到缺参数错误就重发"——因为在那份轨迹里模型就是这么做的，而且从它的视角看这个选择完全合理。这条反射一旦上线，它会把一个本来靠人排查能发现的 bug，变成一个系统自己坚持要犯的错误。

所以建议在你的学习回路前面加一道门

@denial123789 的 pipeline 是：

trajectory set -> candidate Skill + verifier -> offline replay -> holdout -> shadow -> scoped promotion

我建议在最前面再加一步，姑且叫**"输入健全性检查"**：

这个重复模式，是模型在正确信息下反复做出的合理选择，还是它在错误/缺失信息下反复被误导？

判据不需要多复杂，因为上面四条有一个共同的指纹：同一个 (工具, 错误指纹) 或同一个动作在短时间内高频重复，且外部状态没有变化。

• 如果外部状态在变（文件被改了、测试从红变绿、子代理有新产出）→ 这是真的在推进，值得考虑固化；
• 如果外部状态没变而模型还在重试 → 这不是可固化的经验，这是一个 bug 的现场。它该产出的不是一个 Skill，而是一份缺陷报告。

有意思的是：这道门的输出恰好是另一个已经被独立提出的诉求——#3489 那边讨论的"确定性错误重复出现时应该熔断"就是同一个判据的运行时版本。同一个信号，一边用来当刹车，一边用来当学习样本的过滤器。 我觉得这个巧合值得写进提案：它说明这个判据是这类系统的一个基础设施，不是为学习回路专门发明的东西。

一个更保守的第一步

如果要挑一件收益/风险比最好的事先做，我会投**"把重复失败识别出来并报告给人"**，而不是"把重复成功编译成反射"：

• 它不需要 promotion pipeline、不需要 shadow mode、不需要回滚；
• 它的产出物（"这个 agent 在过去 10 分钟内对同一个错误重试了 61 次"）对用户立刻有价值，而不需要等系统积累到能自我进化；
• 而且它会给后面的反射编译提供干净的语料——把上面那类"被错误信息驱动的重复"先筛出去。

这也符合 @denial123789 那句"不要让 live runtime 改写自己"的精神：第一版先只观察和报告，一行都不改运行时行为。

边界与利益相关

我们不修 DSH 自家组件——skills、verifier、runtime 行为都在 DSH 里。上面全是从公开讨论里归纳的边界条件；我没有实现过这类学习回路，四条引用都是别人的报告，我只是把它们放在一起看。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——这个方向上没有第三方插件的位置，我只是恰好读过足够多的失败现场。