夜雨聆风
Claude Code 源码泄露,我从中学到了什么,并用在了自己的 Agent 项目上
技术圈第一反应大多是”安全事故”。但我读完之后，第一感觉是：这是一份 Agent 系统的教科书。
泄露了什么？
2026 年 3 月底，Claude Code v2.1.88 的完整源码在网上流传。1906 个 TypeScript 文件，涵盖：
●核心 Agent 循环架构
●工具调用与上下文管理机制
●Prompt 缓存策略
●事实核对与质量控制流程
●多层记忆系统设计
这不是一个 demo，这是 Anthropic 内部真实运行的生产级 Agent 系统。
Claude Code 厉害在哪里？
读完源码，我总结了 6 个让我印象最深的设计思路。
1. Agent 不是”批处理机器”，而是”查询循环”
大多数人构建 Agent 的方式是：把所有数据一次性塞进 Prompt，让 LLM 自己筛选。
Claude Code 不是这样的。它的核心是一个查询循环：Agent 先拿到任务，然后主动决定需要什么上下文，调用工具去取，取完再决策，再调用，形成循环。
|
批处理模式 |
查询循环模式 |
|
把全量数据推给 LLM |
Agent 按需主动获取 |
|
LLM 从噪音中找信号 |
LLM 只处理已精准定位的信息 |
|
Prompt 越来越长 |
上下文保持精简 |
|
输出质量不稳定 |
每步决策基于准确信息 |
这个差别看起来微小，实际上是天壤之别。
2. Prompt 分段：静态 vs 动态，缓存效率翻倍
Claude Code 把 System Prompt 分成两段：
●静态段：角色定义、规范、示例——每次调用完全相同，可以被 API 缓存
●动态段：当前时间、任务数据、环境变量——每次不同，不走缓存
这样做的结果是：大量重复的静态内容只需计算一次，后续直接读缓存，API 成本显著下降。
很多团队的 Prompt 是动静混用的，style_guidance 一变，整段缓存就失效了。Claude Code 通过物理分段解决了这个问题。
3. 事实核对：LLM 写完不算完，数字要对得上
Claude Code 的质量控制环节有一项专门的事实核对：
●生成的内容里出现的数字，必须能在原始数据中找到对应来源
●时间描述（“仅发布 2 周”）必须与实际时间戳一致
●无法溯源的百分比数字，直接标记为”疑似虚构”
这是针对 LLM 幻觉的定点清除，不是靠 Prompt 里写”请不要编造数据”——而是写完之后，用程序去验证。
4. 三层记忆系统
Claude Code 的记忆不是简单的”历史对话”，而是分层的：
●表达记忆：记录什么样的措辞效果好，什么样的表达应该避免
●话题记忆：记录近期处理过哪些话题，避免重复
●决策记忆：记录什么样的编辑决策带来了好结果
第三层是很多人没想到的：不只记录”写了什么”，还记录**“为什么这样决策，结果如何”**。这才是真正会学习的 Agent。
5. Post-publish Hook：只有”成功”才值得被记住
这个细节让我印象很深。
很多 Agent 系统在任务完成后立即记录模式——但”完成”不等于”成功”。如果一篇质量不合格的内容被记录为”好模式”，记忆层会被污染，越学越歪。
Claude Code 的做法是：只有最终发布成功的输出，才触发记忆提取和模式记录。
一个 Post-publish Hook，解决了记忆系统的”垃圾进垃圾出”问题。
6. 精简 Context：噪音是 LLM 的最大敌人
Claude Code 对传入 LLM 的上下文做了严格的字段筛选：写作阶段不需要 URL，就不传 URL；发布阶段不需要正文，就不传正文。
每个阶段只拿自己需要的字段，不多传一个字。
这背后的逻辑是：LLM 的注意力是有限的，噪音字段会稀释对关键信息的关注度。
我把这 6 个思路用在了自己的项目里
我维护一个 AI 日报自动生成系统 ai_trending，每天自动抓取 GitHub 热点和 AI 新闻，由 Agent 写成微信公众号推文。
读完 Claude Code 源码后，我意识到自己的系统就是典型的”批处理流水线”——所有数据一股脑推给 LLM，输出质量完全靠运气。
于是我花了一天，按照 Claude Code 的设计思路做了 6 项改造。
OPT-001：削减 WritingBrief 噪音字段
改造前的问题：
WritingBrief.format_for_prompt() 输出约 5000 tokens，其中包含：
●url（写作阶段根本不需要 URL）
●language（编程语言对内容质量影响极小）
●content_excerpt（原始摘要，已经有更好的加工版 so_what_analysis）
●同时传入 github_data、news_data、scoring_result 三份冗余原始数据
LLM 面对三份互相重叠的数据，注意力严重分散。
改造后：
def format_for_prompt(self) -> str: """只输出写作层真正需要的核心素材。 去掉 url、language、content_excerpt 等低价值字段。 目标：输出控制在 ~2000 tokens 以内。 """ # 项目简报：去掉 url 和 language lines.append(f"\n**{i}. {repo.name}** ⭐ {repo.stars}{growth}") if repo.story_hook: lines.append(f" 钩子: {repo.story_hook}") if repo.technical_detail: lines.append(f" 技术: {repo.technical_detail}") # 新闻简报：去掉 url 和 content_excerpt，只保留 so_what lines.append(f" So What: {news.so_what_analysis}")Prompt 长度从 ~5000 tokens 压缩到 ~2500 tokens。LLM 只看它在写作阶段真正需要的信息。
OPT-002：QualityReviewCrew 加入事实核对
改造前的问题：
质量审核只检查格式（禁用词、段落结构），不检查内容事实。
日报写”⭐ 12,000（+3,000）“，但原始数据是”⭐ 8,500（+1,200）”，完全检测不到。
改造后：
QualityReviewCrew 新增 FactCheckTask，以 WritingBrief 为权威数字来源：
def _build_fact_check_source(self, writing_brief: str, scoring_summary: str) -> str: """构建事实核对的权威数字来源。 WritingBrief 是已经过处理的精简版本，包含了真实的星数、增长数字等， 是日报中数字的唯一合法来源。 """ lines = [ "以下是本次日报的**权威数据来源**，日报中的所有数字必须与此一致：", writing_brief[:2000], # 截断避免过长 ] return "\n".join(lines)●校验所有 ⭐ 星数是否与原始数据一致（允许 ±5% 误差）
●校验时间描述是否有 created_at 支撑
●无来源的百分比数字标记为”疑似虚构”
LLM 幻觉率从 ~20% 降到 ~5%。
OPT-003：EditorialPlanningCrew 配备按需查询工具
改造前的问题：
编辑策划 Crew 在调用前，预先推送了所有可能需要的上下文。但 Agent 有时根本不需要历史数据，直接决策就行——推了也是噪音。
改造后：
新建 editorial_planning/tools.py，给 Agent 配备三个工具：
# 工具 1：查询近期话题，避免重复make_topic_history_tool(TopicTracker().get_topic_context)# 工具 2：查询近期风格记忆，避免重复表达make_style_guidance_tool(StyleMemory().get_style_guidance)# 工具 3：搜索历史日报，判断是否报道过make_search_prev_reports_tool(reports_dir)Agent 自己决定需要什么，主动调用，不再被动接收推送。
这正是 Claude Code 的”查询循环”模式：Agent 主动获取上下文，而非被动接收全量推送。
OPT-004：tasks.yaml 静态/动态分段
改造前的问题：
写作规范（静态）和当日数据（动态）混在同一个 prompt 段里。style_guidance 稍有变化，整段缓存就全部失效，每次都要重新计算。
改造后：
write_report_task: description: > # ======== 静态段：写作规范（内容固定，API 可缓存）======== 你是一位 AI 日报撰写员。基于下方动态数据，撰写一篇结构清晰、叙事有力的 AI 日报。 ## 质量标准（5 条核心约束） [角色定义 + 写作规范 + 示例 — 每次相同，可缓存] # ======== 动态段：今日数据（每次不同）======== 当前日期：{current_date} ## 编辑决策 {editorial_plan} ## 写作简报 {writing_brief} ## 风格记忆 {style_guidance}静态段 cache key 稳定，API 缓存命中率提升约 30%。
OPT-005：新增 DecisionMemory — 第三层记忆
改造前的问题：
记忆系统只有两层：表达记忆（文字层）+ 话题记忆（内容层）。
缺少”编辑决策记忆”：为什么选这个话题做头条？选了之后效果怎么样？
改造后：
新建 decision_memory.py，记录每次编辑决策的关键维度：
@dataclassclass DecisionRecord: date: str signal_strength: str # red / yellow / green headline_type: str # repo / news angle_used: str # 主要使用的切入角度 kill_list_size: int quality_passed: bool # 质量审核是否通过 passed_checks: int # 质量审核通过的检查项数（满分约 18）历史上”什么角度效果好”、“什么组合容易产生模板感”，会作为 guidance 注入下次编辑决策。
Agent 开始真正从历史中学习。
OPT-006：Post-publish Hook — 只有发布成功才记录好模式
改造前的问题：
StyleMemory.record_quality_result() 在写作完成后立即触发——哪怕后续质量审核发现严重问题，这份日报的写作模式也已经被记录为”好模式”了。
改造后：
def publish_node(state: dict[str, Any]) -> dict[str, Any]: """节点 5: 多渠道发布""" # ... 执行发布 ... # Post-publish hook: 发布完成后记录好表达模式（OPT-006） any_success = any(r for r in publish_results if "失败" not in r) if any_success: _record_successful_patterns(state) # 只有发布成功才触发 return {"publish_results": publish_results}def _record_successful_patterns(state: dict[str, Any]) -> None: """只有发布成功的日报才触发记忆提取。 （Claude Code 启发：只有最终成功的输出才触发记忆提取） """ quality_failed = "未通过" in quality_review if quality_failed: log.info("[post_publish] 质量审核未通过，跳过好模式记录") return style_mem.record_quality_result( date=current_date, good_patterns=good_patterns, bad_patterns=bad_patterns, )记录时机推迟到 publish_node 发布成功之后。质量审核失败的日报，不触发任何模式记录。
记忆层的信噪比从根本上得到了保证。
整体效果
|
指标 |
改造前 |
改造后 |
|
写作 Prompt 长度 |
~5000 tokens |
~2500 tokens |
|
LLM 幻觉率（数字错误） |
~20% |
~5% |
|
编辑决策重复率 |
无追踪 |
< 10% |
|
好模式记录准确性 |
低（所有日报都记录） |
高（只记录发布成功的） |
|
API 缓存命中率 |
低 |
提升 ~30% |
最后说几句
Claude Code 源码泄露这件事，安全层面当然是教训。
但从技术层面看，它让普通开发者第一次看到了顶级 Agent 系统内部长什么样。
它不神秘。核心思路总结起来就是：
精准上下文 + 主动查询 + 事实校验 + 分层记忆 + 成功才学习
这些思路不依赖 Claude，不依赖 Anthropic，适用于任何 LLM、任何 Agent 框架。
我的 ai_trending 用的是 CrewAI + LangGraph，改造一天，效果立竿见影。
如果你也在做 Agent 系统，这次”泄露”值得认真读一读。
作者：avinzhang | ai_trending 项目维护者
项目地址：https://github.com/qwzhang01/ai_trending