Tom Moor：给编程代理补上代码看不到的产品背景

Linear 的 Tom Moor 介绍编程循环之外的智能体背景问题。随着团队从手动操作本地代理转向编排长时间运行的代理，他认为需要系统在整个工作过程中保存背景。

Linear 最初是一款问题跟踪工具，源于团队对缓慢、难用软件的不满。Moor 说，虽然公司成立以来软件开发工具变化很快，他们仍然重视高质量产品。

他回顾从 AI 辅助补全到编程代理，再到更自主的云端工作流的变化。他预计成本和任务持续时间会继续变化，同时承认不清楚长时间运行的代理产出有多少真正上线。

在他看来，问题不只是生成代码。产品必须保持一致：一致性、克制和许多小权衡应相互支持，而不是不断积累互不协调的功能。

编程代理可以读取代码库，却可能不知道原始意图、用户需求、过去的权衡、视觉预期和并行工作。它也可能不了解谁负责决策，或者相关修改为什么曾被回滚。

Moor 建议将这些背景从最初想法贯穿到规划、实现和审查。他以 Linear 的系统为例，但说其他系统也能实现相同原则。

第一阶段是接收工作。想法和报告来自支持系统、聊天、客户沟通、社交媒体、内部团队和监控告警；Linear 将这些信息送入分流流程。

分流代理为工作打标签、分配责任人、归并相关请求、关闭重复项、转交团队，并指出需要澄清的决策。它还会调查问题，并把结果留在问题记录中。

补充后的问题可能包含请求者、客户背景、出现频率、堆栈、监控日志、内部账户信息、相关问题及早期工作的决策。

一个例子中，分流代理调查视频字幕反复开启的问题。它复现了问题，并发现浏览器自动动作被误认为用户意图；这一发现帮助后续修复。

另一个例子中，调查检查了现有代码和类似已发布工作，汇集相关客户，并找到代码库中可能的起点。Moor 认为这为编程代理提供了更丰富的输入。

较小的错误可能在分流后自动修复，其他修改则可由人手动启动，并在本地或云端执行。Moor 认为，验证修改并将 CI 失败反馈给代理的能力至关重要。

接下来是审查。只看代码的代理可能发现逻辑错误，却遗漏更广泛的背景。Linear 将原始问题和补充后的背景提供给另一个审查代理。

审查代理还会查看产品历史，包括受影响区域此前的决策、事故、回归和回滚。知道哪些代码发生变化后，它可以进一步查找相关问题和重叠工作。

完整的编程代理会话可以展示实现期间作出的决策。责任归属则指出谁应当决定产品权衡、哪里可能缺少审查，包括工程团队以外的负责人。

问题因此不只是代码是否正确，还包括这项修改是否适合整个产品。Moor 用 Linear 自己近期的审查案例说明。

一次审查找到了六七个月前的相关修改，并指出一个数据库事务长时间保持打开所带来的事故风险。Moor 说历史背景帮助审查发现了另一次审查没有发现的问题。

另一次审查发现，拟议的界面修改会重新加入此前因过于繁杂而删除的图标。当前代码不一定能直接展示这项早期产品决策。

还有一个例子涉及工作区标签和团队标签的顺序。此前的回滚和相关问题揭示了一项产品约定，而代码库中的单个位置可能看不出这一点。

Linear 构建了一个审查界面，帮助人工审查者理解修改，并展示需要判断的决策。Moor 说，其他审查产品也可以支持相同目标。

最后一个阶段是提炼反馈。问题记录、拉取请求、合并的修改和审查评论不断积累背景，目标是让人的修正超越眼前这一次修改而持续发挥作用。

一项每日自动化会检查已合并工作、审查评论和回滚，提取可执行经验，并加入 AGENTS.md 或相关文档。执行频率可以根据组织的拉取请求数量调整。

Moor 提醒，提示词和累积指令需要不断试验和整理。不能因为每条经验曾经有用，就让指令文件无限增长。

他总结预期效果：接收阶段理解意图，实现阶段参考历史约定，审查阶段查看相关工作，可以减少解决错问题、冲突和返工。

提炼循环再把人的判断带入下一轮工作。Moor 的前提是，随着代码生产成本下降，决定做什么以及保持产品一致性会更加重要。