编码与计算机操作智能体

编码智能体架构

让编码智能体不止是代码生成器的“定位-编辑-验证”循环：智能体-计算机接口、为何智能体式优于流水线式，以及循环在哪里失效。

仓库导航与代码上下文

代码搜索 vs 向量检索、符号级索引、在大型目录树上做上下文预算，以及为何自信的错误定位是代码检索代价最高的失败。

补丁生成与测试驱动循环

结构化 diff 与 hunk 应用失败、测试驱动自我纠错、回归守护，以及循环里的三个诚实骗子：flake、过拟合、被删的断言。

计算机操作与 GUI 智能体

像素 vs DOM 定位、动作空间、截图循环，以及那笔让 GUI 操控成为最后手段的乘法式延迟与可靠性税。

浏览器智能体

把一个真实浏览器当工具来驱动——DOM 与像素两种观察方式、登录与认证状态、踩烂了的失败模式，以及何时该升级到完整 GUI 智能体。

IDE 智能体

住在编辑器里的编码智能体——内循环和 CLI 编码智能体一样，但交互面、撤销预期与信任阈值都不同。

沙箱与安全执行

容器化执行、网络与文件系统隔离、能力作用域，以及当智能体运行不可信、受攻击者影响的代码时如何为爆炸半径做设计。

评估编码智能体

SWE-bench 系列、pass@k vs 解决率、测试编排敏感性、记录在案的污染，以及为何一个截止日期后的私有评测集才是唯一可信的数字。

代码评审智能体

评审机器人的生死取决于精确率而非召回率：以 diff 为锚的上下文、把说不出具体失败场景的发现一律丢弃的对抗性闸门、按最坏优先排序的硬性评论预算，以及作为唯一生产指标的采纳率。

大规模迁移智能体

生成成本归零而人工评审没有，所以交付物是证据而不是补丁：先把判据建好、按可核验性而非按目录分批、把机械的头部交给 codemod、只把尾部交给模型，并让一次百文件试点的无需人工编辑落地比例来决定这个项目是否可行。

调试与分诊智能体

一个读完调用栈就吐出 diff 的智能体是在做模式匹配，不是在调试——把失败的测试定为交付物，评测标准就变得客观，开销从生成挪到观察，而"复现不出来"也成了一个你可以信任的结果。

后台编码智能体

一个每天开十二个 PR 的智能体，如果团队只合得进四个，就什么也没增加——脱离编辑器把瓶颈搬到了复核端，于是每个决策要么是让一次运行能自我验证，要么是把队列压短到工作真能落地。

测试生成智能体

从你的代码出发写测试的智能体，是从实现里反推规格的，所以代码错在哪里，测试就在哪里把 bug 认证为正确并挡住修复——覆盖率看不见这件事，变异得分看得见；而值得派发的任务，只有那些你能用一句话说清判据是什么的。

依赖升级智能体

把版本号往上抬从 2017 年起就已自动化，且一文不值——积压之所以存在，是因为没人愿意合并一个自己担保不了的升级；所以你真正要建的是一份证据规程：全绿的测试恰恰对那些静默出事的默认值变更证明得最少，而正确分流胜过合并数量。

文档智能体

文档是仓库里唯一没有裁判的产物，而写错的一段话会被人信上好几年——所以按"机器能否证伪"切开语料，只在派生型参考与可执行散文上给智能体无人监督的权限，把删除做成一等输出，并报告新鲜度而不是写了多少页。

设计稿转代码智能体

截图没法说出"这是 Button 组件"，于是一个像素级忠实的生成器会重造一个、把十六进制色值硬编码进去而不用 token，并通过你所有的视觉复核——改用组件复用率与 token 遵循度来评判它，把带类型的组件 API 与"设计组件到 import 路径"的映射摆在图片之前交给它；如果十个页面的试点复用率低于七成，你面对的是一个设计系统问题，而智能体只会把它放大。

漏洞修复智能体

生成补丁是便宜的那一半——针对训练截止之后 CVE 的模型补丁里，只有约四分之一在不改变行为的前提下修好了问题；而被你的校验判为正确的那些，一旦改用变异过的利用（而不是别人递给你的那一个）来测，超过四成会挂掉。所以交付物是一份“打补丁前失败、打补丁后通过”的复现，而队列的排序依据是可达性，不是扫描器的严重级别。

以规格驱动的编码智能体开发

计划、测试、代码与总结都源自对任务的同一次理解，于是这次理解一旦错了，每件产物都彼此印证，评审就这么过了——一份规格配不配占位置，取决于它有多大程度来自那个循环之外：由人撰写、以可观察措辞表述的标准，一份明确的非目标清单，每条标准旁边配一个检查项 id 或一位具名的人，以及规格与行为在同一个 pull request 里一起改。

性能优化智能体

别的编码智能体拿到的是不会骗人的核验器，这一个拿到的是秒表——于是四十个候选补丁各测一次计时，几乎必然会留下噪声。先把测量台建好（置信区间、公开的最小可检出效应、固定的重复次数预算），用全量测试套件设关卡而不是把正确性揉进分数，并且交给智能体一份剖析结果而不是一个仓库。

基础设施即代码智能体

别的编码智能体都得自己造判据，这一个白得了 terraform plan——所以交付物是一份「每一行都落进你事先约定可自动执行的类别」的计划，评审工作从读 diff 变成给计划定级，而全部工程难度都在计划只字不提的那四件事上：未知值、服务端行为、与其他一切用同样语气宣布的替换，以及任何不在 state 里的东西。

CI 修复智能体

复现被端到了面前，所以这个智能体真正的工作是那件没人做的分类：由这个 diff 造成、基线上本就存在、基础设施问题，还是非确定性——推送前先把失败的检查对着合并基线跑一遍来证明因果，最多花一次重跑，永远不碰测试所断言的东西，并把告警设在错误推送率上而不是转绿的构建数上。

数据库迁移智能体

模型一次就能写对 DDL——这正是它成为最可能把生产打趴下的那类编码智能体任务的原因：语句没问题，错的是顺序，而 CI 是在一张空表上、没有别人连着的情况下跑它的。把交付物做成「扩展-回填-收缩」这段当前已部署代码依然装得进去的有序序列，把智能体的默认输出设成只增不减，每次都产出 lock_timeout 前导，并用「在带负载的生产形态克隆上做影子应用所实测的锁持有时长」给它打分——智能体负责撰写，受控的执行器负责应用。

Notebook 与数据科学智能体

磁盘上的文件不是产出答案的那个程序——内核才是，而没有任何东西把它记下来，所以在你的外壳执行一次冷启动的"重启并全部运行"给出裁决之前，"它跑通了"是无法证伪的。把那道闸门定为"完成"的定义并当作工具交给智能体，喂它 schema 卡片而不是打印出来的 dataframe，记住危险的边界是数仓凭据而不是沙箱，并且去评那个数字与那套方法，而不是代码跑没跑通。

移动端与原生应用智能体

编码智能体的优势在于一小时错二十次，而一次干净的 iOS 或 Android 构建能在午饭前就把这份预算花光——所以解法不是把构建变快，而是把代码库劈成一个供智能体迭代的快内核，与一个由完整构建按候选把关一次的慢外壳。把模拟器钉死，否则每一次红都是含混的；把已提交的快照参考图立为契约，智能体可以提议但绝不可以接受；并按"每次尝试要几次完整构建"给待办排序。

无障碍整改智能体

把一个扫描分数交给智能体，它会在你自己的仓库里造出一个无障碍覆盖层，因为让一条规则闭嘴最便宜的办法是一个会撒谎的 ARIA 属性——而自动化测试按条数只够到大约一半的失效，且几乎够不到那些会堵死一条旅程的。让工作的单位是一条仅用键盘的用户旅程，在设计系统而不是调用点上修，并要求每个 PR 都带上修复前后的焦点轨迹作为它的证明。

死代码与功能开关清理智能体

删除是编码智能体唯一一件「测试全绿什么也证明不了」的活儿——它通过的理由恰恰就是这段代码看起来已死的理由——而删掉没有测试的代码覆盖率反而上升，于是那个显而易见的目标奖励的正是移除你最不了解的东西。静态分析只提议、从不裁决；证据必须是运行时可达性，窗口按业务日历定，而不是按一个整三十天定。一个被求值一百万次而返回 false 的开关，不等于一个从未被求值的开关；急停开关在每一种启发式眼里都与陈旧开关一模一样；而生产值通常与代码默认值相反。

为智能体写的变更建合并队列

评审不是瓶颈——如今完全未经评审就合入的 PR 多了 31%，事故与 PR 的比值翻了三倍，也就是说系统是靠绕开自己的闸门来吸收这些数量的。剩下的那道闸门，是通往 main 的那条串行路径；而打包这个标准解法在智能体负载下会反转：单 PR 队列失败率 20% 时，十个一组只有 10.7% 的概率通过，每次合并要花掉将近一整趟 CI。按实测的 p 来定批次、坚持要二分定位，并在任何东西入队之前先对着队首变基再核验。

发布与分发智能体

编码智能体的其他每项任务都可撤销，一个已发布的版本不可——npm 的撤回窗口只有 72 小时，版本号永不可复用，而已经解析到它的那些锁文件是永久的。所以设计重心是签名边界，不是自动化：让智能体做版本号、说明与 dry run，并安排成「根本不存在一枚长期有效的发布凭据供它持有」。溯源证明的是产物在哪里构建，不是有人同意把它发出去——所以如果你的智能体能向可信发布所构建的那个 ref 推送，这份证明有效，而它说的是错的那件事。请测量「盖掉所需时间」，并把那条只能向前的修复通路做成智能体能调用的工具。

密钥扫描与轮换智能体

检测是早已解决的那一半，而你正在为它重复付费——2022 年被确认有效的凭据里，在 2026 年重测时仍有超过 64% 有效，所以交付物是一份被证明已死的凭据，连同一张回执。而证明它必须去使用它，这就把架构定死了：智能体只看到指纹，密钥由一个独立的验证器服务持有；智能体可以创建凭据，但永远不可以撤销凭据。