An Accidental Blackboard

意外的黑板

Giles Edwards-Alexander

Giles 是 Thoughtworks 欧洲、中东和印度地区的首席技术官。他在移动技术到人工智能的多个领域拥有超过25年的工程和技术领导经验，涉及的行业包括零售、金融科技和医疗保健。

本文是“探索生成式AI”系列的一部分。该系列记录了 Thoughtworks 技术人员在使用生成式AI技术进行软件开发方面的探索。

2026年9月2日

本周，在 Thoughtworks 欧洲各地，我们召集了10名工程师，将他们安排在巴塞罗那办公室的同一个房间内。我们的目标是观察如果真正投入代理式工程（agentic engineering）会能走多远、多快。我们称之为“超代理式”（hyper-agentic）。在过程中，我们意外地重新发现了关于协调代理的一些东西。

这10名工程师的任务是构建一个航空公司运营中断管理系统（IROps系统）。这是航空公司用于飞行控制中心的系统，当出现异常情况时会使用它。当飞机出现需要维修的技术故障时，当机组成员生病需要更换机组时，他们就是通过这个系统决定取消哪些航班、调换哪些飞机、让哪些乘客下飞机并安排酒店住宿等。他们需要在数百架飞机、数十万乘客和多个站点及机场的大量机组人员之间进行协调。这是一个极其复杂的问题，难以解决，也难以执行。构建、理解和使用一个IROps系统都非常复杂。

我们在四天内成功构建了一个系统。但本文的重点不是讲述我们是如何做到的。

我们从一个规范和一个模拟的航空公司开始，因为这只是一个练习，而不是真正的客户项目。我们尝试了一些方法，只是为了看看哪些可行、哪些不可行。我们使用了单一仓库（monorepo）。所有工程师同时开始工作。我们刚开始时，几天后就看到了一些有趣的现象，一些新的东西开始浮现。

通过调整方法产生的涌现行为

当大量代理在一个仓库中工作时，构建流水线出现了问题。为了解决这个问题，我们引入了一项纪律：代理需要持续提交代码并从主分支重新合并。起初，我们要求每次提交后必须重新合并，然后推送代码，同时所有构建检查和控制措施都到位。我们引入这一变更的目的是为了在本地尽早发现构建失败：频繁且持续地集成。但这也带来了副作用。我们引导代理规划工作，将工作范围限定在规范的特定部分，并创建与这些部分链接的计划。这些计划存储在仓库中。所有代理都使用相同的规范，使用相同编号和标识的章节进行工作。随着代理的工作推进，计划会被更新以记录进度。这些更新，连同其他所有更新，都被新的提交纪律所整合。代理能够看到其他代理的进度。

例如，一个代理可能正在处理评估器（evaluator），即用于判断特定恢复操作计划是否有效的组件，判断该计划是否会违反硬性约束或软性约束等。与此同时，另一个代理可能正在处理搜索算法，该算法用于寻找能够解决中断的计划。搜索组件依赖于评估器。虽然每个组件可以分别编写，但它们共享一个接口，搜索组件依赖于评估器。

这些计划记录了这些集成点。一个计划提到，在这个阶段我需要更新调用者以调用真正的验证器。而在搜索方面，计划提到在这个阶段需要在真正的验证器到达时插入调用。两个代理都能看到每个计划和进度。我们意识到代理们正在利用这些计划进行协调。一个代理会将计划中的某一行标记为进行中，另一个代理看到后就不会处理该行。当第一个代理完成时，另一个代理不仅会看到工作已经完成并可以继续推进，还会直接收到该行是如何实现的说明。

我们开始利用这一点。我们会启动一个会话并引导其专注于特定的旅程。一个例子是将成本模型与验证器一起引入。我们知道其他人正在持续开发成本模型并不断提交代码，因此引导负责验证器的代理查看计划和源码，监控仓库，并在成本模型的工作完成时开始集成。而事实确实如此。

这一切完全是临时起意的。这是一系列决策的偶然结果。我们看到这一现象发生后，便开始利用它。

仓库作为代理的意外黑板

我们代理发现的这种模式有一个名称：黑板系统。这在大学时期我就有所研究。我的研究论文是关于使用分层传感器引导代理行为的。我当时正在研究如何将当时的现代机器学习技术（如强化学习）应用于大规模动态数据集。回顾相关文献后，我将黑板模式作为核心协调结构。这种模式最早在1980年Hearsay-II系统的开发中被发现，随后由Gelernter等人在1986年发展为更正式的元组空间概念。

黑板或元组空间是一种共享内存，自主代理可以独立地从中读写数据。它们读写具有某种最小结构的元组，并可以添加任意数量的额外字段：没有模式限制。这是一种非常有效的技术，可以协调自主问题求解者共同实现单一目标。每个代理可以解决问题的一个分解部分，将解决方案放入共享空间并进行标记，其他自主搜索者会发现它，将其取出并作为自己工作的一部分使用。

我们意外地促使代理开始将仓库用作黑板。但这完全是偶然发生的。这不是有意为之的行为，也没有完全的结构化设计。它缺少黑板系统运作的一些关键部分。由于是偶然发生的，我不确定是否能再次可靠地促使代理这样做。我大致知道我们做了什么，因为我们进行了分析并识别出导致这一连锁反应的单一提示。但这是涌现行为，不是定向行为。

除了要刻意创建这一机制而非偶然发生外，我认为这个通信渠道应该独立于源代码控制之外。虽然我们最初通过引导频繁的提交周期创建了它，但后来我们放弃了这种做法。频繁的提交正在使我们的CI流水线过载。我们改为仅在更连贯的变更块完成时才进行提交。这剥夺了代理持续获取进度更新的流动信息。

一个优秀的意外解决方案需要一个精心设计的有意项目。我开始了一个名为Talwrn的项目，这是威尔士语中"threshing pit"（脱粒场）的含义，指用于解决争论和冲突的场所或空间。该项目旨在成为代理工程的黑板系统。我的目标是开发一个使用极其简单的工具，能够直接集成到你的项目中，并立即为代理提供协调工作的通信渠道。第一步是让Talwrn达到能够支持自身开发的阶段。我计划定期发布进展，因为我希望将其作为纯粹代理工程实践的持续演进示例。

最新文章（9月2日）： 《一个意外的黑板系统》

上一篇文章： 《代理循环中的TDD - 戏剧表演还是实际价值？》 /think