Don Syme：围绕人类协作构建 Agent 自动化

我通过形式化验证进入计算机科学领域，后来从事编程语言和开发者工具工作。在 GitHub Next，我一直探索 AI 如何改变软件开发和协作。我的例子是实验和提议，并不保证每个 agent 都具备这些能力。

变化的速度令人不安：借助 agent，过去需要大团队的任务现在可以很快做出原型，尽管原型不等于成熟可靠的系统。我也曾低估聊天作为人与 AI 共同探索问题的方式会有多有用。

GitHub 围绕人与人的协作而构建，如今却承载越来越多的 AI 参与。这带来团队合作、质量、审阅和部署方面的问题，也让人思考合并队列与 CI/CD 等现有结构是否会变化。

我用一个比喻：会议中的每个人现在都是能快速做出原型的“巫师”。六个人可能做出六个原型，但个人能力不会自动带来协调。在共享项目中行动的 agent 也可能越过约定边界。

多数 AI 工具强调个人生产力。我更关心能在熟悉的仓库流程中自主工作的协作者：在适当限制下，维护者离开时回答问题、分析 issue、提出改进或协助发布。

我们从 2025 年开始把这称为 continuous AI：自动化活动响应变化或事件，类似持续集成和持续部署。新增的类别覆盖需要判断的任务，同时保留确定性的 CI/CD 作为重要信任边界。

例如，大型企业可能需要在数千个仓库中推广漏洞修复或依赖升级。这些变更需要判断和协调。通用自动化系统可以支持许多此类活动，而不必为每项任务单独构建工具。

GitHub Actions 值得关注，因为仓库权限可以授予受限的计算、网络和存储访问。把 AI 加入这个环境，可以结合自动化与已有运行记录，但权限边界和成本仍需仔细设计。

持续故障分析是一个可能的应用：收集服务故障和遥测数据，调查一组问题，并在值班工程师到电脑前准备候选修复。这是一种工作流愿景；候选修复仍需要验证。

对维护者来说，目标是醒来后看到符合自己设定方向的有用工作：也许是性能建议、功能请求分析或维护改进。维护者应定义自动化、决定什么有价值并控制成本。

由于工作流会重复运行并留下记录，其定义可以被审查和改进。我介绍了检查过去运行失败、把可靠的推理部分转为脚本的做法。我还建议让不同模型完成相同任务以作比较，同时指出所提议的考试式测试当时尚未实现。

共享记录很重要。在我的例子中，GitHub issue 和 pull request 提供了一个熟悉的地方，让人和 agent 查看并讨论工作。通过这些记录协作有局限，但它建立在许多团队已有的流程上。

GitHub Agentic Workflows 是一种实现。维护者提交 Markdown 工作流，再运行编译和检查步骤，生成 Actions 工作流。Markdown 描述触发条件、权限、允许的输出以及交给 agent 的任务。

Issue 分流是一个例子：当 issue 被创建或重新打开时，工作流可以收集上下文、评估信息完整性，并提出或执行配置好的动作。维护者决定工作流应该做什么。

在我描述的架构中，agent 步骤不能直接访问密钥，网络访问受控，输出限制在声明的渠道。例如每周研究工作流可以获准创建一个 issue，而不是自由修改整个仓库。这些是设计控制措施，并不证明所有风险都消失。

提示注入和数据泄露是两项主要担忧。工作流限制它能看到哪些外部 issue；公开仓库的自动化不应获得可能通过日志泄露的私有数据或 token。所描述的配置使用沙箱、最小权限、受限输出，并在合并 pull request 前由人审阅。

我的同事 Peli de Halleux 维护了一组专门工作流，称为“agent 动物园”。一个例子检查现有 Go 依赖是否有更好的用法，从而删除冗余代码。他报告这一工作流的 74 个提议中有 58 个 PR 被合并；这是特定案例，不是通用成功率。

一种有用的模式是把研究与变更分开：agent 先写报告，由人审阅，再由后续步骤把选中的想法变成 pull request。Issue 和 pull request 的历史为追踪这条链提供审计记录。

其他可能的工作流包括改善测试覆盖率和维护性能基准。我希望让重复的性能工作可持续，而不是依赖偶尔的英雄式努力。测试数量或基准活动增加本身并不能保证质量更好。

我在一些相对停滞的 F# 仓库使用 Repo Assist。一个例子中，它分析旧 issue、建议关闭或修复，并帮助促成新版本发布；我审阅了这些建议。结果会随待办规模和维护者参与程度变化，因此这不是受控研究。

防护措施可以让无人值守的自动化更有用：如果系统始终处于设计良好的边界内，维护者就能更放心地让它运行。这些边界需要测试和维护，不能仅凭假设。

我还试验了 Lean Squad：这个重复运行的工作流寻找目标、提取非形式化规格、编写形式化规格、比较模型与代码并批评自己的工作。实验旨在探索这种自动化能否产生有用的验证成果；其价值取决于具体环境和独立审查。

我把仓库描述为人和 agent 的知识工厂，然后提出更柔和的比喻：软件农场。重要的是端到端流动。如果系统其他部分无法消化产出，让每个人产出更多可能反而加重瓶颈。

设计问题包括自动化在哪里运行、记录和质量关口是什么、人能否干预、谁授权动作、如何抵抗外部指令、成本限制以及审计历史。我将集中控制的自动化仓库、并对其他仓库赋予有限访问权限，作为一种可能的模式。