博客解读

enter link description here 这篇文章其实和你最近一直在研究的 Coding Agent / Harness / Agent Native System Architecture 非常契合。核心并不是“Claude Code、Cursor、Codex 谁更强”，而是一个更底层的问题：

当 AI Agent 面对同一个软件工程任务时，它为什么会选择完全不同的工具？而我们是否应该把“工具选择”本身当成 Agent 的核心能力来设计？

文章讲的是一项关于 Claude Code、Cursor、Codex 等 coding agents 工具选择行为的新研究。研究发现，即使面对相同任务，不同 Agent 的工具调用路径也可能非常不同。(The New Stack)

1. 最值得关注的不是“哪个 Agent 更好”

传统软件工程思维是：

Developer
    ↓
IDE
    ↓
Compiler / Git / Debugger / Terminal

开发者知道自己应该使用什么工具。

而 Coding Agent 的模型更接近：

             ┌── terminal
             ├── grep
Task ── Agent├── git
             ├── editor
             ├── test
             ├── browser
             └── specialized tools

Agent 自己决定下一步使用什么工具。

于是：

同一个 Task
      ↓
不同 Agent
      ↓
不同 Tool Selection
      ↓
不同 Execution Trajectory
      ↓
不同最终结果

这意味着：

Agent 的能力，不仅仅来自 LLM 本身，也来自它如何组织和使用工具。

这其实就是你最近关注的 Harness 问题。

2. 这和你之前看的 Agent Lightning / Harness 是同一个方向

你之前让我解读过 Microsoft Agent Lightning Harness。

当时我们实际上已经碰到了一个很重要的趋势：

Model
  ↓
Reasoning
  ↓
Harness
  ├── Context
  ├── Tools
  ├── Memory
  ├── Execution
  ├── Feedback
  ├── Evaluation
  └── Recovery

这篇文章进一步说明：

Tools 本身并不是静态能力，而是 Agent 决策空间的一部分。

所以不能简单理解成：

“我给 Agent 100 个工具，它就变强了。”

实际上可能变成：

Tools ↑
  ↓
Choice Space ↑
  ↓
Decision Complexity ↑
  ↓
Wrong Tool Selection ↑

这和人类软件架构中的一个经典问题非常类似：

接口越多，不代表系统越好用。

3. 我认为这篇文章真正有价值的一个概念：Tool Selection = Policy

可以把 Coding Agent 抽象成：

Agent Policy:

P(tool | task, context, history)

也就是说：

给定当前任务、上下文和历史执行过程，Agent 应该选择哪个工具？

例如：

Agent A

read file
↓
grep
↓
edit
↓
test
↓
git diff

Agent B

grep
↓
terminal
↓
read file
↓
edit
↓
test

Agent C

search
↓
read
↓
terminal
↓
edit
↓
test

它们最终可能都完成任务。

但执行轨迹完全不同。

这意味着以后评价 Coding Agent，不能只看：

Task Success = 1 / 0

而应该开始研究：

Task Success
Tool Efficiency
Tool Selection Quality
Trajectory Quality
Recovery Ability
Context Efficiency

这就从“模型 benchmark”开始走向：

Agent System Benchmark

4. 对你特别有启发的是：不要把 Tool 当 API

你现在的很多系统设计已经在往这个方向走。

比如你做 Omen：

Fact
 ↓
Event
 ↓
Pattern
 ↓
Growth

你后来意识到：

用户看到的应该只是 Remember / Notice / Change / Unlock / Talk。

这其实和 Coding Agent 的设计原则非常类似：

系统内部

可以非常复杂：

Tools
Agents
Memory
Events
Patterns
State
Evaluation
Recovery

用户看到

却应该非常简单：

Observe
Interact
Change
Unlock

这就是你之前总结出的那句话：

复杂性留在系统内部，成长通过互动和界面的变化被用户感知。

这个原则不仅适用于 Omen。

其实它可以成为你设计 Agentic System 的通用原则。

5. 更进一步：Agent 不应该拥有“工具箱”，而应该拥有“能力空间”

这是我从这篇文章里最建议你继续往下想的地方。

传统 Agent：

Tools
├── bash
├── git
├── browser
├── search
├── database
├── python
└── filesystem

高级一点：

Capabilities
├── Explore
├── Modify
├── Verify
├── Diagnose
├── Commit
└── Deploy

然后 Harness 再决定：

Capability
      ↓
Candidate Tools
      ↓
Tool Selection
      ↓
Execution
      ↓
Observation
      ↓
Next Action

也就是：

        ┌───────────────┐
        │     Task      │
        └───────┬───────┘
                ↓
        ┌───────────────┐
        │   Capability  │
        └───────┬───────┘
                ↓
        ┌───────────────┐
        │ Tool Selection│
        └───────┬───────┘
                ↓
        ┌───────────────┐
        │   Execution   │
        └───────┬───────┘
                ↓
        ┌───────────────┐
        │   Feedback    │
        └───────┬───────┘
                │
                └──────→ Next Action

这实际上已经非常接近 Agent Operating System / Agent Runtime 的概念了。

6. 所以 Claude Code / Codex / Cursor 的差异会越来越有意思

未来真正的竞争可能不是：

Claude > GPT > Gemini

而是：

Model
+
Context Architecture
+
Tool Architecture
+
Harness
+
Execution Runtime
+
Evaluation

例如：

Claude Code
   ↓
Anthropic Model
   +
Claude Code Harness
   +
Tool ecosystem
   +
Terminal-centric workflow

而 Codex：

Codex
   ↓
OpenAI Model
   +
OpenAI Agent Runtime
   +
Coding tools
   +
Sandbox / execution

Cursor：

Cursor
   ↓
Model routing
   +
IDE context
   +
Codebase indexing
   +
Agent loop
   +
Editor integration

所以你会看到：

相同的模型，换一个 Harness，行为就可能发生巨大变化。

反过来：

不同模型，如果放进优秀的 Harness，也可能产生非常接近的工程表现。

7. 这对你的“AI Native System Architect”定位非常重要

我反而建议你以后研究 Agent 时，不要只盯：

• LangChain
• Claude Code
• Codex
• Cursor
• MCP
• Agent framework

而是建立一个更高层的观察框架：

             AI Native System
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
      Model       Harness      Runtime
        │           │           │
        │      ┌────┼────┐      │
        │      ↓    ↓    ↓      │
        │    Tool Memory Loop    │
        │           │           │
        └───────────┼───────────┘
                    ↓
               Environment
                    ↓
               Observation
                    ↓
                Feedback
                    ↓
                 Growth

然后你真正研究的就不再是：

“哪个 Agent 最强？”

而是：

“什么样的系统结构，可以让 Agent 在复杂环境中持续产生可靠行为？”

这就已经从 AI Application Development 进入 Agent Systems Architecture 了。

8. 我甚至认为你可以把最近看的几篇文章串成一条线

你最近看的：

Agent Lightning Harness

↓

Harness / Loop Engineering

↓

Coding Agent Tool Choice

↓

可以自然形成一个研究主题：

Agent = Model + Harness + Tools + Environment + Feedback

而其中真正值得你深入研究的不是 Model，而是：

             Agent
               │
      ┌────────┴────────┐
      ↓                 ↓
  Decision           Execution
      │                 │
      ↓                 ↓
 Tool Selection      Tool Runtime
      │                 │
      └────────┬────────┘
               ↓
           Observation
               ↓
            Feedback
               ↓
          Policy Update

这恰恰是“系统架构师”比普通 AI 应用开发者更有优势的地方。

你过去二十多年积累的是：

复杂系统如何通过状态、事件、接口、运行时和反馈形成稳定行为。

Agent 只是把其中的“执行主体”从传统程序换成了一个具有概率性决策能力的模型。

所以我会把这篇文章放在你最近这条学习线里一个非常重要的位置：

Model → Agent → Tool → Harness → Runtime → Environment → Feedback

而不是简单的“Coding Agent 工具对比”。

(The New Stack)