从前言来看，打破黑盒

许多开发者在使用 AI 编程助手时常常陷入两大误区：

• 把它当作“黑盒”——只要输入需求就期待完美代码。
• 认为模型拥有百万级。只要把背景信息塞进去，效果就会提高。

在处理简单、独立的小任务时这种模式确实高效。但在真实的公司级项目中——几十万行代码、上百个组件、跨模块业务逻辑，新旧代码共存——这种“黑盒模式”很快就会崩溃。你会发现 AI 开始胡说八道、无视架构约定，甚至写出技术上正确但业务上致命的代码。

痛点一这方面。期望与现实的巨大落差

你可能已经体验到：一次“修复登录 bug”的请求，最终得到的是一段与项目架构不符的代码；或者 AI 在关键位置出现了拼写错误，却因为上下文被稀释而没有及时发现。

至于痛点二。过度依赖大上下文导致噪音堆积

把几十个文件一次性塞进模型，让它自行挑选关键信息，往往适得其反。无关信息越多，模型关注的主要细节越容易被淹没。

第一篇 原理篇

回答最基础的问题：Coding Agent 到底是怎么工作的，它又为什么会在复杂代码库里失真？

第 1 章 Coding Agent 的工作原理

LLM 的本质：自回归 + Attention 机制

大语言模型做的事只有一句话：预测下一个 token。它没有独立思考过程——推理即生成。每一步只产出一个 token，接下来再继续预测。这就是自回归。

Attention 机制让模型在生成新内容时扫描整个，并为不同位置分配权重。理论上，它可以照到任何位置，但实践中有三大限制：

**幻觉雪球效应**：软件开发是“长链路、强约束”过程，一旦模型早期猜错了函数名或 API，就会在后续步骤中不断自洽扩散错误，直到编译报错才被纠正。

• 模型推理本质是一种概率续写，而非逻辑推演。
• 上下文质量远比数量关键——塞进几十个文件并不会让模型更聪明，而是让信号被稀释。
• **关键结论**：理解自回归 + Attention。你才能看到两件事：

1. 推理是概率续写，而非逻辑推演；其实，
2. 上下文质量比数量关键；

再看强化学习。从“会说话”到“会做事”

预训练让模型学会了 GitHub 源码的大体结构，但它像一个看过所有烹饪书却从未进厨房的人。真正赋予 Coding Agent 行动能力的是强化学习: 它定义了什么叫做成功，而不是怎么做成功。奖励信号通常基于测试通过率和代码质量评分。

• 模拟环境执行编程任务；
• 用测试通过率作为奖励；
• 学习何时读取更多文件、何时直接修改、如何提取错误信息等策略；

TIPS: 对齐 RL 奖励信号才能让 Agent 更好地完成任务。说到例如，“修复登录会话未保存的问题。运行 npm test 应全部，Agent 表现越好。

Agent Loop：主要运行循环

The agent loop is a multi-step cycle that keeps refining its actions: