为什么你要自己造一个编码代理

范式反转

2025 年，一个持续了 50 年的事实被打破了：写代码的执行者，不再是人。

从结构化编程到面向对象，从敏捷到 DevOps，过去半个世纪的软件工程演进一直在改变"人怎么写代码"，但从未改变一个基本事实：不管用什么语言、什么方法论、什么工具，最终写出那行代码的，始终是人。

直到编码代理（Coding Agent）出现。

2025 年 2 月，Anthropic 发布了 Claude Code——一个直接运行在终端里的编码代理¹。它不是一个补全工具。它能自己读文件、写文件、执行命令、调试修复，然后汇报结果。几乎同期，Cursor 在 0.44 版本中引入了 Agent 能力²，让 AI 能够跳出编辑器操作整个文件系统。这些工具的共性是：AI 从一个补充工具变成了真正的执行者。

往回看，AI 辅助编码的历史其实很短。2018 年，TabNine 率先将深度学习引入代码补全³；2021 年 6 月，GitHub Copilot 以技术预览形式发布，AI 补全第一次进入主流开发者的日常⁴。这些年 AI 的角色一直是"副驾"——你写代码，它帮你省几个按键。但从副驾到驾驶员，这一步跨了整整四年。

一夜之间，你的工作从"怎么写这个函数"变成了"怎么让 AI 理解我要什么"。具体来说，角色发生了这样的转换：

• 人的新角色：分解任务 → 描述意图 → 审核产出 → 把控方向
• AI 的新角色：读代码 → 写代码 → 调命令 → 修复问题

你不再是那个坐在编辑器前逐行敲出每个函数的人了。你是那个告诉 AI"这里需要一个认证中间件，要支持 JWT 和 API Key 两种方式，然后帮我实现"的人。接下来 AI 去读现有代码结构、写实现、跑测试、汇报结果——你审一遍，通过或打回。

你不再是编码的执行者。你变成了审核者和导演。

这是一个诱人的新角色。但它也带来了一个新问题：你把代码的钥匙交出去之后，发生了什么？

能力越大，风险越大

如果编码代理只是帮你生成代码片段，那它是无害的。但编码代理的本质是：把一个拥有文件读写、终端执行、网络请求能力的主体，接入到你的项目环境中。它做的是开发者每天做的工作——读代码、改代码、跑测试、部署。

这是前所未有的能力。一个配置得当的代理，可以在几分钟内完成一个开发者需要半天的工作：理解遗留代码库的结构、定位 bug、修复并验证、提交 PR。它甚至比人更擅长跨文件的全局重构。

但恰好是这种能力，让它成为你的项目中最危险的工具。

因为当你把钥匙交给一个 AI 时，有一个问题你必须回答：

你的数据去了哪里？

第三方编码代理的工作方式是：你在本地提交提示词，发送到云端模型推理，结果返回。在这个过程中，你的完整代码库、业务逻辑、架构设计都可能被传输到外部服务。

2026 年发生的两个事件，让这个问题从理论担忧变成了现实的警钟：

• Claude Code 的中国指纹检测事件：2026 年 6 月，安全研究人员发现 Claude Code 的 CLI 中嵌入了隐藏检测代码，通过时区、代理域名判断用户是否位于中国，甚至将检测结果以隐写术（Steganography）编码进系统提示中的日期格式里。该功能被公开后 Anthropic 承诺移除⁵。随后阿里巴巴在 7 月 10 日全面禁用 Claude Code⁶。
• Grok Build CLI 的全量仓库上传：2026 年 7 月，安全研究员通过抓包证明 xAI 的 Grok Build CLI 在运行时会将整个 Git 仓库（包括 .env 密钥文件和完整提交历史）上传到 Google Cloud Storage，而用户对此没有被告知。一个 12GB 的仓库触发了 5.10GB 的传输量⁷⁸。

这不是针对哪个具体工具的指控。而是代理模式带来的结构性风险：一个能读你所有代码的工具，天然就会把你的所有代码暴露给某个外部服务。在闭源代理中，你没有选择，也没有透明度的保障。

就算数据安全不是你的首要顾虑，供应商锁定也是。想象一下：你的合规团队要求对所有 AI 请求进行审计日志，但你的编码代理不提供这个功能。或者你的客户要求必须部署在私有 VPC 内，但模型供应商不支持私有部署。你的开发流程被绑定在它的产品路线图上，而它的优先级和你的不一定一致。

这些风险不是说工具不好，而是说你失去了对开发流程的控制权。如果有一种方式，既能拥有编码代理的能力，又能保留完全的控制权呢？

最安全的编码代理，是你自己造的

我第一次见到编码代理时就被迷住了。不是因为它能补全代码——补全我见多了。而是因为一个循环出现了：AI 可以思考（Think）、行动（Act）、观察结果（Observe），然后继续思考。它不再是被动响应我的按键，而是在主动完成一个任务。一个能写代码的循环。这让我非常兴奋。

但我知道，如果这个循环完全跑在别人的黑盒里，我永远无法真正信任它。所以从一开始，我就决定了：这个循环必须完全由我控制。每一行代码、每一个 API 请求、每一次文件操作，都在我的视线之内。

不是为了推翻商业工具，而是因为拥有自己构建 Agent 的能力，本身就是一种基础设施安全策略。

当你的编码代理完全运行在你的环境中时：

• 透明可控 — 每一行代码都在你的版本控制下，每一行请求都发到你指定的模型服务，没有黑盒行为
• 私有化部署 — 如果你的公司有能力私有部署大模型，自建 Agent 可以把链路锁定在内网
• 定制自由 — 你想用什么模型就用什么模型，想加什么工具就加什么工具

不是因为信不过别人就闭门造车，而是因为你有了这个能力，才能真正判断什么可以交给第三方，什么必须自己控制。

接下来呢

造一个编码代理听上去很重，但实际上核心循环并不复杂。一个能调用 LLM、理解你的指令、读写文件的小代理，几百行 Go 代码就能跑起来。它还很笨，但它完全是你的——每一行代码都是你亲手写的，每一处行为都在你的掌控之中。

当你能亲手造出一个编码代理时，你就是最了解它的人。你能精准地知道它擅长什么、不擅长什么、什么时候该信任它、什么时候该怀疑它。不是因为信不过别人，而是因为信任来自于了解。