我先给你第一轮“偏专业、偏架构”的调研结论。结论先放前面：这次 Claude Code 泄露真正有价值的，不是“拿到了一堆代码”，而是行业第一次大规模看清：一个高成功率 coding agent 的核心护城河，很大一部分其实在 harness，而不只是模型本身。 多家报道都把这次外泄描述为暴露了其内部“harness / orchestration”层；Anthropic 自己近几个月的工程文章也几乎在同一方向上反复强调：上下文管理、工具设计、会话切分、权限控制、测试闭环、评测体系，这些外围系统设计，决定了长任务能不能做成。(The Guardian)

1）事件本身，值得你关注的不是八卦，而是“架构曝光”

这次事件目前高可信的公开信息是：Anthropic 在一次发布中因打包失误，把 Claude Code 的内部源码相关内容带了出去，媒体普遍提到规模大约接近 2,000 个文件、50 万行代码级别；Anthropic 表示没有泄露客户数据，也不是模型权重泄露，而是内部产品实现与架构层面的暴露。也就是说，这次外流对想研究“coding agent 是怎么真正落地”的人，价值远高于对想研究模型本身的人。(The Guardian)

很多分析文章都提到同一个关键词：Claude Code 并不是“套了 shell 的聊天模型”。公开镜像与拆解里反复出现的是：工具注册表、任务层、权限系统、内存层、MCP 集成、IDE bridge、后台/并行任务、slash commands、session 恢复等一整套产品化系统。eWeek 那篇虽然是媒体转述，但抓到的重点是对的：真正被“看光”的不是某个 prompt，而是一整套“让 agent 长时间稳定干活”的工程堆栈。(eWeek)

2）专业解读里最重要的共识：harness 比 prompt 更重要，context engineering 比单次提示更重要

Anthropic 官方文档现在已经直接把 Claude Code 定义为一种 agentic harness：模型负责推理，工具负责行动，而 Claude Code 本身负责“工具、上下文管理、执行环境”。这和很多人想象的“主提示词写好一点就行”完全不是一个层级。Anthropic 在 context engineering 文章里也明确说，构建 agent 已经越来越不是“prompt engineering”，而是“什么样的上下文配置最有可能稳定地产生你要的行为”。(Claude)

这点和外界对泄露代码的分析高度一致。eWeek/Neuron 的解读把重点放在 memory、permissions、state management、session recovery、background jobs、team coordination 这些“听起来不性感，但决定项目会不会翻车”的部件上；VentureBeat 也把它概括成“一张高 agency、可商用 agent 的蓝图”。这两类来源角度不同，但指向同一件事：高质量 vibe coding 的关键不是让模型更敢写，而是让系统更会约束、校验、切换上下文、恢复状态。 (eWeek)

3）从公开逆向和专家拆解里，能提炼出的高价值架构经验

A. 记忆系统不是“越多越好”，而是“索引化、按需加载、持续清理”

这是我认为对你最重要的一条。

公开逆向分析里，Yuyz 的结论很鲜明：如果你想复刻强 agent，真正值得学的不是某份还原代码，而是它与 LLM API 之间的交互模式；换句话说，不是照抄实现，而是看它如何在不同任务阶段组织上下文、工具和状态。(GitHub)

围绕这点，eWeek/Neuron 对外界分析的总结里提到一个很关键的判断：Claude Code 的 memory 更像 受约束的检索系统，而不是把一切都塞进长期笔记本；轻量常驻层负责指路，专题知识按需取回；不把本可从代码重新推导出的内容固化进记忆；记忆还会重写、去重、清理矛盾，把 stale memory 当风险而不是资产。这个判断和 Anthropic 官方 memory 文档是互相印证的：官方明确写了每个 session 都是新的 context window，跨会话依赖的是 CLAUDE.md 和 auto memory，而且 auto memory 只加载前 200 行或 25KB，显然是有意控制记忆体量和常驻预算。(eWeek)

对你的 harness 启发：
不要做一个“大而全的 agent memory”。更好的做法是三层：

1. 常驻层：项目目标、技术栈、约束、代码规范、验收标准。
2. 专题层：数据库、前端、支付、部署、测试等 topic files，按需取。
3. 运行层：当前任务 plan、todo、失败日志、最近决策，只保留短期工作集。
   这样能明显降低 context 污染，减少 vibe coding 后期“越写越飘”。(Claude)

B. 高成功率不是靠单 agent 硬撑，而是靠角色分化

Anthropic 2026 年 3 月的 harness 文章已经把这一点讲得很直白：他们从单 agent 推进到多 agent，采用 planner / generator / evaluator 三角色结构，用结构化产物在多会话之间交接上下文。(Anthropic)

Anthropic 更早的多 agent research system 文章也说过，复杂开放问题很难靠单线 one-shot pipeline 解决，因此让一个 agent 先规划，再开并行 agent 去不同方向检索或执行，是更稳定的做法。社区对 Claude Code 的 Task/Explore 子代理研究，也强调了子代理的核心价值：独立上下文、防膨胀、并行执行、只把相关结果返回父代理。(Anthropic)

对你的 harness 启发：
别让一个 agent 既做 PM、又做架构师、又写代码、又验收。更好的最小形态是：

• Planner：拆解任务、定义 done criteria、决定先做什么。
• Builder：只管实现。
• Evaluator / QA：跑测试、做浏览器验证、检查需求符合度。
• Research / Retrieval（可选）：只负责搜 repo / docs / issue / design notes。

这会比“一个万能 vibe coder 从头写到尾”成功率高很多。(Anthropic)

C. 长任务要靠结构化交接物，不是靠会话记忆硬续命

Anthropic 在 long-running harness 相关文章里反复提到，长任务的难点之一是上下文窗口逐渐变脏、模型开始失去连贯性，甚至出现他们称作 “context anxiety” 的现象：模型因为感觉窗口快满了，开始过早收尾。解决办法之一是把任务拆成可处理的小块，并通过结构化 artifact 在 session 之间 handoff。(Anthropic)

他们官方 best practices 也明确说了：Claude 的上下文窗口是最重要的稀缺资源，随着 session 填满，性能会下降。(Claude)

对你的 harness 启发：
你需要让每次子任务结束时，强制输出这些中间件：

• 当前目标与边界
• 已完成 / 未完成
• 修改文件清单
• 测试结果
• 阻塞点
• 下一步建议
• 回滚点 / 风险点

也就是让 agent 靠 artifact 接力，而不是靠“记得住”。这对大项目尤其关键。(Anthropic)

4）工具层的经验：工具不是越多越强，而是越“省 context、可筛选、可组合”越强

Anthropic 关于 tools 和 MCP 的两篇文章，几乎可以直接当你设计 harness 的工具层原则：

第一，不要把所有工具定义都一次性塞进模型上下文。他们指出，随着 MCP server 和 tools 增多，预加载所有工具定义会显著拖慢 agent、增加 token 成本。更优做法是 progressive disclosure：按需搜索工具，只读当前任务相关定义。(Anthropic)

第二，大数据不要直接穿过模型。Anthropic 介绍 code execution with MCP 时说得很清楚：如果让模型直接接收大工具结果，中间数据会两次甚至多次流经上下文；如果把工具以代码 API 的方式暴露给 agent，让 agent 在执行环境里筛选/变换数据后只回传必要结果，token 和错误率都会降很多。他们文中举的案例是把 token 消耗从 150k 降到 2k，约 98.7% 的节省。(Anthropic)

第三，工具返回值要天然适合 agent 消费。Anthropic 建议给大输出做分页、范围选择、过滤、截断，并且错误信息要“可操作”，而不是一串 opaque tracebacks。Claude Code 默认把工具响应限制在 25,000 tokens，也是同一逻辑。(Anthropic)

对你的 harness 启发：
你自己的工具层建议这样设计：

• search_code, search_docs, search_logs 分开，不要一把梭。
• 所有检索工具默认只返回摘要 + 指针，不返回全文。
• 所有列表类工具支持 limit, offset, range, detail_level。
• 大型工具结果先在沙箱里预处理，再把结论给模型。
• 工具错误永远返回“下一步怎么修正参数”。
  这会直接提升大项目生成代码的稳定性。(Anthropic)

5）真正提高项目构建成功率的，不是“会写代码”，而是会验证代码

Anthropic 的 long-running harness 文章有个特别实用的点：给 agent 配浏览器自动化和测试工具之后，效果会明显提升，因为它可以自己发现那些“代码看上去对，但功能没通”的 bug。文章还提醒，某些 bug 是因为工具本身看不到，例如浏览器原生弹窗。这个提醒很重要：你的 agent 质量上限，常常取决于它的验证工具上限。 (Anthropic)

Anthropic 的 harness 文章和 C compiler 多 agent 文章也都在强调：要把任务变成可验证的目标，让 agent 有“自检回路”，而不是只凭语言自信。(Anthropic)

对你的 harness 启发：
如果你现在主要做 vibe coding 项目，我建议至少接四类验证器：

• 单元 / 集成测试
• lint / typecheck / build
• 浏览器 E2E
• 截图比对 / 视觉检查

然后把默认 loop 变成：实现 → 运行验证 → 读错误 → 修复 → 再验证。
这比单纯“生成更多代码”更能拉高成品率。(Anthropic)

6）Hook / 生命周期拦截，是 Claude Code 里很值得借鉴的一层

官方 hooks 文档显示，Claude Code 的 hook 生命周期相当丰富：SessionStart、UserPromptSubmit、PreToolUse、PermissionRequest、PostToolUse、SubagentStart/Stop、TaskCreated/Completed、PreCompact、PostCompact、SessionEnd 等，说明它不是把 agent loop 当黑盒跑，而是给了很多 orchestration 切点。(Claude)

这对你自己的 harness 很关键。
因为很多项目失败，并不是模型不会，而是缺少这些“拦一下”的时机：

• 改文件前先检查目标是否明确
• 调高风险工具前先跑 policy
• context 压缩前先做状态摘要
• 子代理结束后强制产出 handoff artifact
• 会话结束时自动沉淀 memory / lessons learned

这比继续给主 prompt 加条款更有效。(Claude)

7）安全经验：高 autonomy 必须绑定沙箱与权限边界

这一轮调研里，安全线索也非常强。

Anthropic 自己在 sandboxing 文章中说，Claude Code 默认权限模式容易带来 approval fatigue，于是他们引入了 文件系统隔离 + 网络隔离 两条边界；内部观察到沙箱能把权限提示减少 84%。他们还强调，两者缺一不可，否则 prompt injection 仍可能读密钥或外传数据。auto mode 文章则提到，用户实际上会批准 93% 的权限请求，所以仅靠频繁弹窗并不靠谱。(Anthropic)

另一方面，Check Point 在 2026 年 2 月披露过 Claude Code 的相关漏洞，攻击面正是 hooks、MCP servers、环境变量等项目配置机制，可导致 RCE 和 API key 外泄；已与 Anthropic 协作修复。这个案例提醒得很到位：agent 的扩展能力，就是它的攻击面。 (Check Point Research)

对你的 harness 启发：
你想做更强的 agent，就必须同步做这几件事：

• 默认只给工作目录读写权限
• 网络访问白名单化
• 工具按 risk tier 分级
• 对 hooks / MCP / project config 做不可信输入审查
• 敏感数据流走 execution layer，不走 model context
• 尽量让 git/push/deploy 经过代理层二次校验
  否则 autonomy 一强，事故率也会一起升。(Anthropic)

8）从“大神/专家经验”里能抽出的几个实操共识

我这轮搜到的社区材料里，最有价值的不是情绪化讨论，而是几类稳定共识：

第一类来自公开 prompt / system prompt 研究。Piebald 的仓库持续从 Claude Code 编译产物里抽取 prompt 组件，并指出 Claude Code 实际上不是“一条总 system prompt”，而是大量条件拼接的 prompt 片段、工具描述、Plan/Explore 子代理提示、压缩/记忆等 utility prompts 共同构成的。这说明你自己的 harness 不要迷信单个超级 prompt，应该做成 prompt graph / prompt layers。 (GitHub)

第二类来自子代理研究。johnlindquist 的 Task/Explore deep dive 强调，Task 工具的本质是把工作委派给轻量子代理，独立上下文、并发、只回传关键发现。这和 Anthropic 官方多 agent 文章方向完全一致。(Gist)

第三类来自 HN/开发者经验。相关讨论里，很多开发者认为 Claude Code 真正厉害的地方不只是模型，而是良好的 CLAUDE.md 结构、架构决策、文件路径约定、行为规则，以及对修正反馈的持续沉淀。虽然 HN 不是一手技术规范，但它反映了高频用户的稳定经验：规范化项目记忆比堆更多事实记忆更值钱。 (Hacker News)

9）把这些结论翻译成你自己的 harness，最值得照抄的不是源码，而是这套骨架

如果你的目标是“提高项目构建成功率，优化 vibe coding 流程，提高生成代码质量”，那我建议你把第一版 harness 设计成下面这个最小闭环：

入口层

• 用户目标
• 项目约束
• 验收标准
• 技术栈 / 环境探测

认知层

• 常驻 memory（短小）
• topic memory（按需）
• 当前任务工单 / plan artifact

执行层

• planner agent
• builder agent
• evaluator agent
• retrieval/research agent（可选）

工具层

• 代码搜索 / 文档搜索 / 日志搜索
• 文件读写
• shell / sandbox
• tests / build / lint / browser
• issue / git / deploy（后置）

控制层

• PreToolUse / PostToolUse hooks
• task handoff hooks
• compact / summarize hooks
• risk policy / permission classifier

评估层

• task success
• first-pass success
• retries
• files changed
• tool error rate
• token / latency
• human takeover rate
• regression rate

这套骨架和 Anthropic 官方近半年的工程文章、公开逆向、社区 prompt 拆解的方向是高度一致的。(Anthropic)

10）我对你这个项目的直接建议：先别急着“复刻 Claude Code”，先复刻它的成功约束

你真正该吸收的，不是某些泄露里看起来很酷的内部 feature，而是下面这 6 个硬原则：

1. Memory 是索引，不是仓库。
2. Agent 要分角色，不要万能单体。
3. 任务必须有结构化 handoff artifact。
4. 工具按需暴露，结果尽量别全进 context。
5. 默认 loop 必须带验证。
6. 高 autonomy 必须配沙箱、权限和审计。

这些原则几乎在官方 docs、工程博客、逆向研究、社区拆解里都能找到对应证据。(Claude)

---

这只是第一轮研究。我下一轮可以继续往更“落地”的方向推进，直接帮你输出一版 面向你自己 harness 项目的架构蓝图：包括目录结构、memory 设计、agent 分工、hook 点位、任务状态机、以及适合 vibe coding 的评测指标体系。