一条 Prompt 进入 Agent 后，到底经历了什么才变成代码？
你以为打了一行字，Agent 就直接开始写代码了？
这中间其实隔了至少五道工序：拼上下文、模型推理、工具循环、落盘编辑、验证收口。
看懂这条流水线，你才会明白为什么同一个 prompt 有时一次到位、有时反复返工——问题常常出在你看不见的中间环节。
Prompt 不是直接发给模型的
你输入的那句话，只是最终请求的很小一部分。
Agent 会先做一次「上下文装配」，把这些东西一起塞进发给模型的请求里：
- 系统提示词：定义角色、工具用法、行为边界。
- 项目说明书：比如
AGENTS.md、CLAUDE.md里的构建命令和约定。 - 可用工具清单：Read、Edit、Bash、Grep……每个工具的参数说明。
- 历史消息：之前的对话和工具调用结果。
- 环境信息：当前目录、操作系统、日期时间。
所以你写「修一下登录 bug」，模型实际看到的是几千甚至几万 token 的一整包材料。
这也解释了为什么 AGENTS.md 写得好，Agent 表现会明显变稳——它是每次请求都在场的常驻输入。
模型第一步往往不是写代码
收到装配好的上下文后，模型做的第一个决策通常是：先调工具，而不是直接输出。
因为「修登录 bug」这个目标信息不够，它需要先侦察：
- 用 Glob/Grep 找到登录相关文件。
- 用 Read 读代码和报错日志。
- 必要时跑一下测试复现问题。
每调用一次工具，结果会被追加回上下文，模型再决定下一步——这就是 Agent 的核心循环：
| |
这个循环可能转几圈到几十圈，直到模型认为信息足够，才会进入编辑阶段。
编辑代码不是「重写整个文件」
到了真正动手的时候，主流 Agent 用的是最小编辑，而不是整文件重写。
以典型的 Edit 工具为例，它要求：
- 先读过目标文件，不能凭记忆改。
- 给出精确的
old_string和new_string，原文必须唯一匹配。 - 一次只改一处，改坏了容易定位。
这样做有两个直接好处：diff 小、可审查；上下文里也不用来回搬运整个文件。
新建文件才会走整体写入。所以你看到的「Agent 改代码」，本质是模型生成了一批结构化参数，由工具层执行校验后才真正落盘。
改完不等于结束，还有验证收口
负责任的 Agent 流程不会停在「文件已保存」。
编辑之后通常还有一轮收口动作：
- 跑测试或构建，确认没把别的地方弄坏。
- 静态检查：lint、类型检查、编译报错。
- 如果验证失败，把错误信息再喂回模型，进入新一轮循环。
这也是为什么一个复杂任务会跑很久：推理-工具-编辑-验证这个环会反复转，直到验证通过或 Agent 判断走不下去为止。
哪个环节最容易翻车
对应到日常使用，常见问题基本能映射到流水线的某一环：
- 上下文装配差：需求描述含糊、
AGENTS.md缺失，模型只能瞎猜。 - 侦察不足：没读关键文件就开改，改错位置。
- 编辑粗糙：让 Agent 大段重写而不是小步编辑，diff 失控。
- 跳过验证：跑完命令不看结果，错误一路带到最后。
想让 Agent 干活稳，其实就是把每一环的输入喂好：写清需求、维护好项目说明、要求小步修改、盯一下验证结果。
Meta（发布信息）
建议标题：
- 一条 Prompt 是怎么变成代码的？
- Agent 写代码前的 5 道隐藏工序
- 你的 Prompt 进了 Agent 之后经历了什么
- 看懂 Agent 流水线，Prompt 不再玄学
正文描述
你以为输入一句话 Agent 就直接写代码？其实中间隔着上下文装配、模型推理、工具循环、落盘编辑、验证收五道工序。这篇用一条流水线讲清 prompt 从输入到代码落地的全过程，并指出每个环节最容易翻车的点，适合想让 Coding Agent 干活更稳的开发者收藏。
参考资料
- Kimi Code CLI 的系统提示词与工具定义（本地会话实际可见）
- Claude Code / Codex 等主流 Coding Agent 的公开文档中关于工具循环与编辑工具的设计
话题标签
#AI编程 #CodingAgent #Prompt工程 #ClaudeCode #KimiCode #AI工具 #程序员 #LLM #开发效率 #Agent原理
封面： cover.png（由 baoyu-xhs-images 生成；若生成失败会在此注明原因）