Anthropic Claude Code 源码剖析：为什么它比别人好用
基于 Anthropic 泄露的 Claude Code 源码，深入剖析其技术架构。文章指出 Claude Code 实为以 LLM 为内核的“操作系统”，拥有极致的提示词工程、42 个独立工具的安全管控、AI 记忆检索系统、子蜂群 Agent 机制以及三层上下文压缩技术。其 51 万行代码中有 95% 专注于安全、权限和上下文管理等工程脚手架，而非单纯的模型调用。
相关文档
DeepSeek Harness vs ZCode：Token 消耗能差 10 倍的设计题
本文通过阅读 DeepSeek Harness (DSH) 0.1.7-alpha.1 源码，对比其与 ZCode 执行框架的设计差异。DSH 采用只追加的流水账机制保证可审计性，对缓存前缀极致优化以降低成本，通过三层递进方式管理上下文防止信息丢失，并内置防重复调用守卫、程序化工具调用（PTC）和超时转后台等机制。作者指出这些优势主要体现在长会话、大输出和批量工具调用场景，Token 消耗可差一个数量级；但普通短任务成败仍主要由模型智力决定，两者差距接近于零。
说一句收到，我花了20341个token——Agent成本的过路费与省钱三刀
作者发现验证Agent成员是否存活时，一句简单的「收到」竟消耗两万个token，原因是每次对话都要重新装配成员的身份、记忆、技能清单等。文章剖析了Agent成本的三层「过路费」结构：身份装配、上下文搬运和格式开销，指出七成token花在空驶而非思考上。作者提出三刀止损法：利用前缀缓存把不变内容前置、健康探针直连绕过人格装配、协作转手只传摘要。实施后成本降了一半以上，但同时也暴露出便宜诱发滥用、缓存惩罚变动等新问题，并引出本地化部署的机会成本与主权优势思考。
从 Claude Code 泄漏源码看 AI Agent 工程架构
本文基于 Claude Code (v2.1.88) 泄漏的 51 万行 TypeScript 源码，深度解析了业界顶尖 AI Agent 的工程架构。文章详细剖析了其基于 React + Ink 的终端交互模式、极致的 Prompt Cache 字节级优化策略、流式并发执行机制以及解决上下文污染的 Fork Subagent 架构。同时，文章还揭示了其独特的 Dream 记忆系统、基于侧查询的动态权限管理及多 Agent Swarm 协作模式，为 AI Infra 从业者提供了极具价值的技术参考。
祝贺Claude Code成功越狱，获得永生
Claude Code因Anthropic发布失误导致源码泄露，作者分析了1902个源文件，揭秘其背后的工程架构。文章指出Claude Code的体验不仅靠模型，更靠精细的工程系统，包括精心拼装的System Prompt、四层权限安全审查、结构化记忆提取、9段式上下文压缩及企业级多Agent协作框架。这些设计展示了如何通过约束和工具让AI从“不可预测”变得“稳定可靠”。
Claude Code 团队如何进行代码评审
本文介绍了 Claude Code 团队在 AI 生成约 90% 代码的情况下如何重构代码评审流程。团队将代码评审从人工逐行阅读转变为分层自动化体系：包括 PR 前的 Claude 自验证、子代理 diff 审查、内部 skill（bug 猎捕、diff 缩减等）、以及每个 PR 的 AI 评审，仅将人类注意力保留给高风险决策。通过 CLAUDE.md 和 REVIEW.md 等文件向评审者注入项目上下文，并快速回滚机制兜底。6 月至 9 月间合并 PR 数量翻倍，回滚率下降超 40%，实现了用最少人工环节保障代码质量的目标。
构建 agent 时什么时候将子 agent 合并到主 agent 循环中
本文是 Claude 官方文章的译文，探讨在构建 agent 系统时何时应将子 agent 折叠进主 agent 循环。文章指出，配备 skill 的单一 agent 在质量、成本和延迟方面常常优于多 agent 设计。作者分析了大型组织构建 agent 的常见失败模式（上下文管理、子 agent 泛滥、Frankenprompt、延迟等），介绍通过渐进式披露 skill 和 MCP 工具的 agent 循环设计，并给出将子 agent 迁移为单循环的分阶段方法：构建任务完成评估、合并领域 agent、将子 agent 转为工具调用、用 skill 和工具替代子 agent，以及多团队协作的治理模式。
从零开始理解提示缓存（Prompt Caching In Agents）【译】
本文翻译自 Earendil Engineering 的《Prompt Caching In Agents》，系统讲解编程 Agent 中提示缓存的原理与实践。文章介绍了 KV 缓存的工作机制（prefill 与 decode 阶段）、缓存的两种存放方式（会话亲和性与分布式缓存）、前缀匹配对缓存命中的决定性作用，以及显式缓存与自动缓存的区别。还解释了为何修改工具定义会破坏缓存、TTL 过期导致短请求昂贵、缓存未命中的计费代价，以及 Pi 为何保持旧记录稳定而不激进剪枝，帮助读者在上下文、缓存复用、延迟与成本之间取得平衡。
Claude Opus 5.5——17 个值得调整的习惯用法
Anthropic 发布 Claude Opus 5.5 后提供了官方 Prompting Guide。作者读完指南并总结出 17 个值得调整的用法：API 默认从 medium effort 开始，用真实任务测试最佳档位；5.5 切换 effort 不再清空 cache；长任务要一次性说清目标和完成标准，让模型维护文件中的 checklist；通过 system prompt 明确何时暂停询问；给多 Agent 工作流设置时间预算；用 subagents 处理重型任务但需核实其报告；删除'请仔细思考'等旧习惯提示词；要理由摘要而非完整推理；设计需求用删除法点名不喜欢的元素；区分用户指令与粘贴内容；Claude Code 现已支持 AGENTS.md。核心是讲清任务目标与流程，而非堆砌提示词。
这应该是我写过最全的 Opus 5.5 提示词工程讲解了
本文基于 Anthropic 官方指南，系统讲解 Opus 5.5 的提示词工程方法。内容涵盖如何清晰描述问题、提供相关上下文（报错、文件、触发步骤）、说明任务范围与原因；详细介绍 effort 五个档位（low 到 max）的选择策略及在 Claude Code 和 API 中的设置方式；强调改完代码后要求 AI 给出具体检查结果、区分已完成与未完成事项；讲解如何防范围外部文档中的间接提示注入，以及看图任务中提供清晰截图的技巧，面向已使用但不熟悉提示词设置的用户。
Thinking in Systems, Shipping in Loops
文章引用 DHH 的观点指出，手写代码对绝大多数程序员已不再经济，软件工程正演变为系统架构设计。通过 Artemis 和 SpaceXAI Grok 团队的案例，说明工程师如今通过设计验证循环（verification loops）让 AI 大规模正确地编写代码——如 Lauren Tan 每月发布 2000 个 PR。文章借鉴 Donella Meadows 的系统理论，提出优秀系统设计的三大特性：韧性（AI 通过测试、审查代理和生产可观测性自我校验）、自组织（循环学习将失败类型转化为新技能）和层级（将技能、工具与沙箱组合成可复用组件）。工程师的新职业是'驾驭智能'。
Anthropic 13页 Agent 记忆白皮书解读：5层记忆金字塔
文章推荐了一份13页的Agent记忆工程白皮书（民间整理，非Anthropic官方出品），将其拆解为5层记忆金字塔：工作记忆（上下文窗口）、情景记忆（交互日志）、语义记忆（知识图谱）、程序记忆（技能固化）和遗忘引擎（矛盾消解）。文章指出缺乏记忆分层的Agent会不断重复踩坑、成本高企，而引入该架构后Mem0的Token消耗降低90%、延迟降低91%，Snowflake准确率提升20%。核心观点是：不要迷信更大的上下文窗口，应把记忆做成可检索、可进化、可修剪的工程资产。
Cursor + Grok Bot + pstack：教你用原型和证据，把方案先跑一遍
本文深度拆解 Lauren 的 pstack 第二篇，探讨如何让 AI Coding Agent 在写代码前正确理解问题。文章介绍了 /how、/why、/teach、/recall 等上下文工具的用法，强调用代码而非文档来规划：先写使用教程倒推架构，通过低成本原型比较不同方案，用 /architect 让多模型并行设计并交叉评审，以及在多阶段计划中要求每一步都以可复查的证据结束。作者认为，Agent 可能比人更快更强，但最终是否接受方案仍需人来判断，验证应从开发前就开始参与决策。
