大家好，我是 iDao。10 年全栈开发，做过架构、运维，也在落地 AI 工程化。这里不搞虚的，只分享能直接跑、能直接用的代码、方案和经验。内容包括：全栈开发实战、系统搭建、可视化大屏、自动化部署、AI 应用、私有化部署等。关注我，一起写能落地的代码，做能上线的项目。
最近很多人在聊 Claude Code，标题一个比一个猛，最常见的说法就是"源码泄露"。
但如果你真在做 Agent 产品，这个事最值得盯的，其实不是"有没有人看到了代码"，而是另一件更扎心的事：一旦构建产物把 source map、工具描述、提示分层和运行时假设一起带出去，别人看到的就不只是实现细节，而是你这套 Agent 到底怎么被驯化出来的。
这也是我觉得这件事值得单独写一篇掘金文的原因。它不是单纯的吃瓜新闻，也不只是安全事故复盘。它更像一堂公开课：把 AI Agent 产品里那些平时不太会被写进 PRD 的隐性资产，硬生生摊到了台面上。
先把边界说清楚：基于目前能公开引用的资料，更稳妥的表述不是"Anthropic 完整源码泄露"，而是围绕 Claude Code 的构建产物 / source map 暴露，外界得以观察到更高密度的实现线索、工具定义、提示策略片段和运行时假设。官方可直接引用的资料，主要还是 Anthropic 文档里关于 Agent Skills、Slash Commands 这些公开能力说明；其他内容，更适合写成公开报道或社区分析，而不是写成官方实锤。
一、为什么这件事会让工程师这么上头？
因为在传统软件里，source map 往往只是调试辅助文件；但在 Agent 产品里，它可能连着另外几层东西一起暴露出来。
普通 Web 应用被看见 source map，大家担心的是源代码可读性、目录结构、变量命名、业务逻辑泄露。到了 Agent 产品，这个风险直接升级。因为一个 Agent 真正值钱的部分，往往不只是"功能代码"，而是下面这些东西如何被组织起来：
- 模型在什么场景下该调用哪个工具
- 提示词是怎么分层的，系统约束和任务约束怎么拼接
- 高风险动作在什么条件下会被拦截、追问、降级或拒绝
- 遇到上下文过长、命令失败、权限不足时，系统会怎么兜底
换句话说，source map 一旦和工具 schema、prompt 片段、权限逻辑同时变得可见，暴露的就不再只是"代码怎么写"，而是"产品脑回路怎么设计"。
这点对 AI Agent 团队特别要命。因为很多团队真正花时间打磨的，从来都不是一个函数怎么命名，而是那套 orchestration：模型、工具、约束、回退策略，怎么拼起来才既能干活，又不容易失控。
二、这次更接近"暴露了什么"，而不是"泄露了多少代码"
我更倾向于把这类事件拆成四层看，而不是一句"源码泄露"打包带走。
1）构建产物层
这是最表层，也是争议的入口。公开讨论里反复出现的关键词是 npm 包、build artifact、source map。也就是说，问题的起点更像是发布出去的构建产物保留了过多可观察信息，而不是大家传统理解里的"代码仓库被完整拖走"。
2）产品逻辑层
这层才是开发者真正会盯住的地方。因为当你能看清某些工具描述、调用边界、策略分支时，你会开始反推：这个 Agent 到底怎么决定什么时候读文件、什么时候执行命令、什么时候停下来问用户。
这不是"看到几行代码"的问题，而是能否看出产品行为背后的编排结构。
3）提示词与策略层
很多团队总把 prompt 当文案看，觉得"被看到也无非就是几句话"。这其实是低估了 prompt 在 Agent 产品里的地位。
在这种系统里，prompt 往往不是一段散装说明，而是和 tool schema、permission policy、上下文拼接规则一起工作的控制层。只要这些东西同时被看见，别人就更容易理解：你是怎么让模型少犯错、少越权、少跑偏的。
4）社区推断层
最后一层是最容易写歪的。公开报道、博客、社区帖子会基于可见线索做大量推断，其中有些推断很有启发，有些则明显超前。所以写这类文章时，边界一定要卡住：
- 官方文档能证实的，就按官方文档写
- 公开报道提到的，就按公开报道写
- 社区推断，只能写成社区推断
这一步看着保守，但很重要。否则文章很容易从"技术拆解"滑到"脑补内幕"。
三、Agent 产品里，为什么 source map 比你想的更敏感？
因为 Agent 的竞争力，本来就不全在模型本身。
大模型厂商今天谁都能接，推理能力差距也越来越不是唯一壁垒。真正把产品拉开差距的，往往是工程层：
- tool definitions 写得够不够细
- prompt layering 是否稳定
- permission policy 有没有写死在代码护栏里
- runtime assumptions 合不合理
- fallback logic 能不能在模型失手时把系统拉回来
这些东西，很多不会出现在营销稿里，却会实打实决定产品上限。
举个很直接的例子。一个 Agent 是否靠谱，不取决于它会不会说"我可以帮你完成任务"，而取决于它在准备执行 shell 命令、修改文件、访问仓库、遇到上下文爆炸时，到底会走哪条分支。这些分支如果能被看得很清楚，别人拿走的不只是经验，而是你调了无数轮才沉淀下来的系统策略。
所以这件事给我的最大提醒不是"以后别发 source map 了"这么简单，而是：在 Agent 时代，source map 已经不是单纯的前端调试问题，它可能直接碰到产品方法论。
四、公开文档本来就说了什么？这次额外多出来的又是什么？
这也是个容易被忽略的点。
其实如果你看过 Anthropic 的公开文档，会发现 Claude Code / Agent 相关的表层结构并不神秘。像 Agent Skills、Slash Commands 这些概念，本来就在官方文档里公开出现过。换句话说，外界早就知道这类产品大概长什么样。
真正让工程师兴奋的，不是"原来它有技能系统""原来它有命令机制"这种事，而是更深一层：
- 这些公开概念在实际产品里是怎么串起来的
- 哪些规则是写在 prompt 里，哪些是写在 runtime 里
- 哪些地方靠模型自觉，哪些地方靠代码强拦截
- 出问题时，系统的兜底逻辑可能长什么样
这就是"知道产品有这个功能"和"看见功能背后的实现哲学"之间的差别。
前者是产品说明书，后者才是工程底牌。
五、给 AI Agent 团队的 5 个工程提醒
如果你正在做 Agent、Copilot、AI IDE、自动化工作流工具，我觉得下面这 5 条比吃瓜本身更有用。
1）把发布产物审计提到和权限审计同一个级别
很多团队会做密钥扫描、依赖漏洞扫描、权限审计，但对构建产物审计很粗。Agent 产品不能再这么做了。
你得检查的不只是 .env 有没有混进去，还要看：
- source map 有没有被带出去
- 构建后文件里有没有 prompt 模板
- tool schema 是否以高可读形式暴露
- 权限枚举、策略分支、fallback 提示是否可直接逆向
2）别把 prompt 当文案资产管理
普通聊天产品里，prompt 泄露已经够尴尬；到了 Agent 产品里，它往往直接参与行为控制。
如果一套 prompt 实际承担了角色边界、任务约束、风险提示、工具调用说明，那它就不是"写给模型看的文案"，而是产品控制面的一部分。既然如此，就该按资产来管理，而不是按运营文案来管理。
3）高风险动作一定要代码级护栏，不要只靠模型自觉
这是最老派，但也最实用的一条。
别迷信"我在 system prompt 里强调过不要越权"。模型会忘、会误判、会被上下文带偏。真正能兜底的，还是代码里的硬约束：确认机制、权限判断、白名单、显式拦截、回退路径。
一句话：能写死在运行时逻辑里的，就别只写在 prompt 里。
4）从攻击者视角再看一遍你的客户端和包产物
你平时是站在开发者视角看系统：这个功能能不能跑通、调用链顺不顺、提示语是否自然。
但上线前，最好换个视角再看一遍：如果我是外部研究者、逆向工程师、竞争对手，我能从你的包里看出什么？
这个视角一换，很多之前看起来无害的内容就会变得刺眼：注释、schema、报错文本、策略分支名、未清理的模板、调试残留。
5）别低估"运行时假设"本身的价值
很多团队把运行时假设写得到处都是，比如：默认当前目录是项目根目录、默认环境里有 git、默认某类命令失败后应该自动重试、默认遇到危险操作要停下来问。
这些假设平时不显山不露水，但它们决定了产品是否顺手。真被别人看明白了，对方抄走的不是一个函数，而是一整套"让 Agent 更像产品、没那么像 demo"的经验。
所以，Claude Code 这次事件最值得行业记住的，可能不是"有没有泄露源码"这句标题党，而是另一句更工程的话：
Agent 产品真正脆弱的地方，早就不只在源码仓库里了。
它还在 source map 里，在 tool schema 里，在 prompt layering 里，在 permission policy 里，在那些你以为只是实现细节、其实已经构成产品核心能力的隐性资产里。
如果你在做 AI Agent，这事最好别只当新闻看。它更像一次提醒：以后保护构建产物，不只是为了防别人看代码，而是为了防别人把你的产品脑回路整包带走。
关注 【iDao技术魔方】，获取更多全栈到AI可落地的实战干货。