Agentic Coding Harness本质是上下文编排，非智能本身

所谓「Agentic Coding Harness」，本质上是「上下文编排工具」，而非智能本身 -- 来自 @SemiAnalysis_ 关键认知：LLM 是无状态的 这是理解所有 harness...

所谓「Agentic Coding Harness」，本质上是「上下文编排工具」，而非智能本身 -- 来自 @SemiAnalysis_ 关键认知：LLM 是无状态的 这是理解所有 harness 的前提。底层模型（Claude Opus、GPT 系列）没有任何跨请求的记忆。每一次调用，模型都是从零开始处理你塞给它的全部内容。 这意味着 harness 必须在每一轮交互中，把以下三样东西完整重建并发送： · 系统提示 · 工具定义 · 消息历史 也正是这个特性，使得 prompt caching 成为降本提速的关键工程项——重复的前缀不必每轮重算 KV cache。 一次请求的三件套 1. System Prompt：定义人格 + 注入当前环境状态 -- "你是 Claude Code"、文件树、最近 git commit 2. Tool Definitions：声明模型可调用的能力 -- Bash、FileRead 等的 JSON Schema 3. Messages：编年体对话史 -- user / assistant 交替，含 thinking blocks 与 tool 调用结果 注意：环境状态（文件树、git log）是被注入到 system prompt 里，而不是模型自己"看到"的。模型从不直接接触你的文件系统——它读到的是 harness 替它转写的文本。 Agentic Loop 的工作流 线程给出标准的 plan → act → verify → repeat 骨架，落到工程上是这样一条 HTTP 流水线： Harness 组装请求 (system + tools + messages + cache_control + max_tokens) │ ▼ HTTP POST LLM Server │ ├── 无 tool_use → 返回文本 → 呈现给用户 │ └── 有 tool_use → 返回 JSON 描述 │ ▼ Harness 在本机执行（如跑 Bash） │ ▼ 将 tool_output 追加回 Messages │ ▼ 发起下一轮请求（回到顶部） 关键细节：工具执行发生在用户的本机，不在服务器。LLM 只返回"想做什么"的 JSON 意图，真正动手的是 harness。这既解释了为什么这些工具能修改你的本地文件，也解释了为什么权限/沙箱边界如此重要——攻击面就在本机执行这一环。 不同 harness 的真正差异点 Claude Code、Codex、OpenCode 这些工具遵循同一套骨架，区别只在两处： · 上下文管理策略——如何压缩、取舍、缓存 growing 的 message history · TUI/UX 设计——人如何与 loop 交互 换句话说，"harness engineering" 决定的是体验和效率（响应速度、上下文不爆、操作顺手），不决定智能上限。智能天花板由模型本身决定。 点睛之笔："Everything else is just REST all the way down." 这句话有意颠覆 "agentic" 这个词带来的神秘感。剥离掉营销话术后，整套机制就是： · 一个持续运行的 HTTP 客户端 · 维护一段不断增长的 messages 数组 · 在"模型决策 → 本地执行 → 回填结果"之间循环 · 直到模型不再调用工具，把控制权交还给用户 没有魔法，只有循环 + REST + JSON Schema。 SemiAnalysis @SemiAnalysis_ Everyone's always talking about agentic coding harnesses: Claude Code, Codex, OpenCode, Pi... the list goes on. But what's the difference between all of them? What even Is a harness anyway? In this thread, we'll take a look under the hood. (1/5)🧵 🔗 View Quoted Tweet 💬 5 🔄 0 ❤️ 6 👀 1042 📊 6 ⚡