IDE 智能体。
住在编辑器里的编码智能体——内循环和 CLI 编码智能体一样，但交互面、撤销预期与信任阈值都不同。Cursor、Continue、Cline、GitHub Copilot 的智能体侧、JetBrains AI Assistant：内层循环依然是编码智能体架构那篇里的「定位-编辑-验证」模式，但每一次交互都包在一层用户正在实时观看的界面里。这件事改变了"好行为"的定义。
核心循环一致，所在的接触面完全不同。
IDE 智能体仍然是一个定位-编辑-验证的循环：读取仓库、提议变更、应用变更，并在理想情况下用测试、类型检查或 lint 自我核验。编码智能体架构一文里的每一条都适用——智能体-计算机接口仍是承重面，定位仍决定结果，验证器仍在挣它的工资。
真正不同的是循环周围的东西。用户就坐在编辑器前，看着每一次光标移动、每一处 diff、每一个"正在应用……"的进度。这里没有"自信的后台进程"这种待遇——它有观众。
"可撤销"就是契约。
IDE 智能体应用的每一处变更，都必须能被 Ctrl-Z 撤销。这一条没得商量。在编辑器里，撤销是用户的安全原语；绕开它（通过编辑器追踪不到的进程直接写文件）的智能体，等于打碎了用户"我随时能退回去"的基本心智模型。结果是用户先按 Ctrl-Z、再卸载。
把每一处变更走的，和用户自己敲字走的，是同一个编辑器 API。如果做不到，至少把一次智能体回合的所有变更打成一组事务性的撤销组——一次 Ctrl-Z 退回整个回合。永远不要绕过编辑器的追踪历史去直接写磁盘——那条路看起来更快，却会训练用户害怕你的工具。
三种不同的交互模式——按特性挑一种，别混用。
IDE 智能体这块阵地已经收敛到三种模式，多数用户的困惑都来自把它们搅在一起：
- 行内补全。亚秒级、字符级、低仪式感。用户在打字，智能体把这一行或这一块补完。接受动作是 Tab 键。延迟预算：几十到一两百毫秒。
- Diff 建议。智能体提出一个多行或多文件的变更，作为可审阅的 diff 呈现。用户接受、拒绝，或先改再接受。延迟预算：以秒计。
- 原地改写 / 智能体式编辑。智能体拿到一个目标（"把这段重构成用新 API"），自己规划、编辑、可能跑一次测试，最后把成品改动呈上来。延迟预算：几十秒到分钟级。
每个特性都该挑准模式。一个偶尔停 10 秒去做规划的"行内补全"是坏掉的行内补全。一个按字符流式呈现的"原地改写"，等于邀请用户在中途去"纠正"，于是和光标打一架。每种模式都有自己的 UX 契约；把它们混在一起，会产出一种"哪里不对"却谁都说不清的界面。
IDE 智能体比 CLI 编码智能体多需要的那些状态。
CLI 编码智能体面对的是一棵已检出的工作树。IDE 智能体面对的是一个活的、不断变动的工作区，要把活儿做对，需要更多的状态：
- 光标位置与选区。不知道"这"指什么，"重构这里"就退化成了"在某处重构点什么"。
- 打开的缓冲区，而不仅是磁盘上的文件。用户在另外三个文件里有未保存的修改；智能体必须基于缓冲区内容推理，而不是基于过期的磁盘内容。
- 撤销历史。"撤销你刚才那一下"这句话隐含的是：智能体知道自己刚才干了什么——在 IDE 里，撤销栈是智能体工作记忆的一部分。
- Lint 与类型检查状态。编辑器里已经在跑的实时诊断是廉价的信号；不把它们喂给智能体，就是白扔一个免费的验证器。
一个只对磁盘文件操作的 IDE 智能体——就像早期的 CLI 编码智能体那样——会稳定地踩到用户正在进行的工作，并产生与模型能力毫无关系的错误。
IDE 这块接触面上特有的失败模式。
四种形态在生产里反复出现，值得提前防御：
- 覆盖未保存的缓冲区。智能体读磁盘，用户在缓冲区里有未保存的修改，智能体经编辑器把内容写回——用户的编辑被悄悄丢掉了。只要缓冲区存在，就通过编辑器读，而不是通过文件系统读。
- 毁掉用户的选区。一次"原地改写"在改写途中丢掉了用户的选区，使他只能盯着改完的代码而无法轻易再选回去继续打磨。改写完成时要保留或恢复选区。
- 接受后光标乱跳。接受一条建议之后，光标被丢到文件末尾（或被重构 hunk 的第 0 列），打断心流。把光标恢复到一个合理位置——通常就是用户接下来要键入的地方。
- 无声的部分应用。智能体提议了一份五段 hunk 的 diff；其中两段未能应用（文件在提议与接受之间被移动了）；编辑器只显示三个绿色对勾，没有报错。用户以为变更全落地了。Hunk 应用失败必须暴露出来，不能默默降级。
IDE 是一块高信任接触面——用户在看、动作就发生在他自己的工作流里、回归的代价会出现在他下一次代码评审里。请用至少与模型层和工具层一样的认真程度对待交互层；在编辑器里，接触面就是产品的一半。