An Accidental Blackboard意外的黑板

This week, across Thoughtworks Europe, we took 10 engineers and put them in one room in our Barcelona office. The goal was to see how far and how fast we could go if we really leant into agentic engineering. We called it hyper-agentic. Along the way, we accidentally re-discovered something about coordinating agents.本周，Thoughtworks欧洲分部的10名工程师齐聚巴塞罗那办公室。我们的目标是看看如果真正投入到智能体工程（agentic engineering）中，我们能走多远、走多快。我们将此称为“超智能体”（hyper-agentic）。在这个过程中，我们意外地重新发现了关于协调智能体的一些规律。

The 10 engineers were given the goal of building an airline IROps system. This is the system that airlines use in a flight control centre when something goes wrong. When a plane has a technical fault that needs to be repaired. When a crew member gets sick and the crew needs to be replaced. It’s how they decide which flights to cancel, which planes to swap, which passengers get offloaded and put into hotels, etc. etc. They’re doing this over hundreds of aircraft, hundreds of thousands of passengers and many, many crew across multiple stations and airports. It’s a really, really hard problem, hard to solve, hard to execute. An IROps system is complex to build, complex to understand, and complex to use.这10名工程师的任务是构建一个航空公司IROps（不正常航班运行）系统。这是航空公司在飞行控制中心处理突发状况时使用的系统。比如当飞机出现技术故障需要维修时，或者当机组人员生病需要更换时。它决定了航班如何取消、飞机如何调换、乘客如何被安排下机并入住酒店等。他们需要处理数百架飞机、数十万名乘客以及分布在多个站点和机场的众多机组人员。这是一个极其困难的问题，无论是解决还是执行都非常复杂。构建、理解和使用IROps系统都绝非易事。

We managed to build one in four days. But this post isn’t about how we did that.我们成功在四天内构建出了一个原型。但这篇文章并非要介绍我们是如何做到的。

We started with a specification and a simulated airline, because this was a practice exercise, not a real client. We tried a couple of things just to see what would and wouldn’t work. We used a monorepo. All the engineers began working at once. We just got started, and after a couple of days we began to see things happening in interesting ways, things emerging.我们从一份规范和一个模拟航空公司开始，因为这只是练习，而非真实客户项目。我们尝试了几种方法来观察哪些可行、哪些不可行。我们使用了单体仓库（monorepo），所有工程师同时开始工作。项目启动后，几天内我们便观察到了一些有趣的现象，一些自发涌现的行为。

Emergent behaviour from tuning our approach调整方法后产生的涌现行为

With lot of agents working in one repo, build pipelines suffered. To deal with this we introduced a discipline: our agents were to continually commit and rebase from main. At first, we required a rebase after commit and to then push, with all of the build checks and controls in place. We introduced this change to catch build failures locally: integrate early and often. But, there was a side-effect. We were directing the agents to plan, to scope work to sections in the spec and to create plans linked to those sections. These plans were stored in the repo. All agents were working off the same spec using the same numbered and identified sections. As agents worked, plans were updated to record progress. These updates, alongside all others, were swept up with the new commit discipline. Agents were able to see other agents’ progress.由于大量智能体在同一个仓库中工作，构建流水线不堪重负。为了应对这种情况，我们引入了一项准则：要求智能体持续提交（commit）并从主分支进行变基（rebase）。起初，我们要求在提交后必须先变基再推送，并配合所有的构建检查和控制流程。我们引入这一变更旨在及早发现本地构建失败，即“尽早且频繁地集成”。然而，这产生了一个副作用。我们引导智能体进行规划，将工作范围限定在规范的各个部分，并创建与这些部分关联的计划。这些计划存储在仓库中。所有智能体都在使用同一份规范，并参考相同的编号和章节。随着智能体的工作，计划会不断更新以记录进度。这些更新与其他所有变更一起，被纳入了新的提交准则中。于是，智能体能够看到彼此的进度。

So, one agent was, say, working on the evaluator, the component to determine if a particular plan to restore operations is valid, whether it breaks hard constraints or soft constraints, etc. At the same time another agent was working on the search algorithm that looks for plans that could solve the disruption. The search component depends on the evaluator. Each component can be written together, but there is a shared interface and search depends on the evaluator.假设一个智能体正在处理评估器（evaluator），即判断恢复运行的特定计划是否有效、是否违反硬性或软性约束的组件。与此同时，另一个智能体正在处理搜索算法，寻找能够解决中断问题的方案。搜索组件依赖于评估器。虽然每个组件可以分开编写，但它们共享接口，且搜索组件依赖于评估器。

The plans recorded these integration points. One plan said at this point I’m going to need to update the callers to call the real verifier. And on the search side, it said, at this point I need to insert the call to the real verifier when it arrives. Both agents could see each plan, and the progress. We realised that the agents were using the plans to coordinate. One agent would mark a line of the plan as in progress, the other agent would see that and not work on that line. When the first agent finished, the other agent would see not only that the work was complete and thus it was released to proceed, but would also be directly delivered notes on how the line had been implemented.计划记录了这些集成点。一个计划中写道：“在此处，我需要更新调用方以调用真实的校验器。”而在搜索侧，计划写道：“在此处，当校验器准备好时，我需要插入对它的调用。”两个智能体都能看到彼此的计划和进度。我们意识到，智能体正在利用这些计划进行协调。一个智能体会将计划中的某一行标记为“进行中”，另一个智能体看到后就不会去处理那一行。当第一个智能体完成后，另一个智能体不仅能看到工作已完成并可以继续，还能直接获得关于该行是如何实现的注释。

We started to exploit this. We’d kick off a session and direct it to work on a particular journey. One example was to introduce a cost model alongside the verifier. Knowing that someone else had been working on the cost model and pushing commits continually, we directed the agent working on the verifier to look at plans and source, monitor the repo, and when the work for the cost model lands start to integrate it. And it did.我们开始利用这一点。我们会启动一个会话，引导它完成特定的任务。例如，在校验器旁边引入一个成本模型。由于知道有人正在处理成本模型并持续提交，我们引导处理校验器的智能体去查看计划和源码，监控仓库，并在成本模型的工作落地时开始集成。它确实做到了。

This was entirely ad hoc. It was an accident of a series of decisions. We saw it happen. And then started to use it.这一切完全是即兴的，是一系列决策后的意外收获。我们观察到了它的发生，并开始加以利用。

The repo as an accidental blackboard for agents作为智能体意外“黑板”的仓库

There’s a name for the pattern our agents had discovered: a blackboard system. This was something I explored back in my university days. My research thesis was in directing agent behaviour with hierarchical sensors. I was looking at applying modern machine learning techniques of the time, such as reinforcement learning, across large, dynamic datasets. Looking back over the literature, I adopted the blackboard pattern as the core coordination structure. This had previously been discovered in the development of the Hearsay-II system in 1980. It had been subsequently been developed into the more formal tuple space concept by Gelernter et al. in 1986.我们的智能体所发现的这种模式有一个专门的名称：黑板系统（blackboard system）。这是我在大学时代曾探索过的领域。我的研究课题是通过分层传感器来引导智能体行为。当时我研究的是将现代机器学习技术（如强化学习）应用于大型动态数据集。回顾文献，我将黑板模式作为核心协调结构。这一模式最早在1980年Hearsay-II系统的开发中被发现，随后在1986年由Gelernter等人发展为更正式的元组空间（tuple space）概念。

A blackboard or tuple space is a shared memory that autonomous agents can read and write from independently. They read and write tuples with a certain minimum structure, and then as many extra fields as you want: no schema. It’s a very effective technique for coordinating autonomous problem solvers towards a single goal. They can each solve a decomposed part of the problem, drop their solution into the shared space, label it, and other autonomous searchers will find it, pick it up, and use it as part of their work.黑板或元组空间是一种共享内存，自主智能体可以从中独立读写。它们读写具有一定最小结构的元组，并根据需要添加任意数量的额外字段，无需模式（schema）。这是一种协调自主问题求解器实现单一目标的极其有效的技术。它们各自解决问题的分解部分，将解决方案放入共享空间并进行标记，其他自主搜索者便能发现、获取并将其作为自身工作的一部分。

We had accidentally prompted our agents to start using our repo as a blackboard. But it was an accident. It wasn’t an intentional act. It wasn’t fully structured. It was missing some of the key parts of how blackboards operate. And because it was accidental, I’m not convinced I would be able to reliably prompt our agents into doing it again. I’ve got a pretty good idea what we did, because we did some analysis and identified the single prompt that caused this cascade to start happening. But it was an emergent behaviour. It wasn’t a directed behaviour.我们意外地促使智能体开始将我们的仓库当作黑板使用。但这纯属偶然，并非有意为之，也并不完全结构化。它缺少了黑板运作的一些关键要素。正因为它是偶然发生的，我不确定能否可靠地再次引导智能体这样做。我大致知道我们做了什么，因为我们进行了一些分析，确定了导致这一连锁反应的单一提示词。但这是一种涌现行为，而非定向行为。

As well as creating this intentionally, rather than accidentally, I believe you want this communication channel to be sitting independently of source control. While we created it by directing a frequent push cycle, we backed-off from that. The frequent commits were overloading our CI pipeline. We switched to only push when a more coherent chunk of change was complete. This deprived the agents of the continuous flow of updates on progress.除了将这种机制从偶然变为有意为之，我认为你还需要让这个通信通道独立于版本控制系统之外。虽然我们是通过引导频繁推送周期来创建它的，但后来我们退出了这种做法，因为频繁提交让CI流水线不堪重负。我们改为仅在完成一个更连贯的变更块时才推送，但这剥夺了智能体获取持续进度更新的能力。

A good accidental solution requires a good intentional project. I’ve started working on a project I’m calling Talwrn. That’s Welsh for a threshing pit, an area or space where arguments and conflict get worked out. This is aiming to be a blackboard for agentic engineering. My goal is a very simple to use tool that drops straight into your project and immediately offers a communication channel for agents to coordinate work. The first step is to get Talwrn to a point where it can support its own development. I’m planning to post about it regularly as I’m hoping to use it as a single, evolving example of how pure agentic engineering can proceed.一个好的意外解决方案需要一个好的意向性项目。我已开始着手开发一个我称之为“Talwrn”的项目。这是威尔士语，意为“打谷场”，即解决争论和冲突的地方。这旨在成为智能体工程的黑板。我的目标是提供一个使用极其简单的工具，能够直接放入你的项目中，并立即为智能体协调工作提供通信通道。第一步是让Talwrn能够支持自身的开发。我计划定期发布关于它的文章，希望能将其作为一个单一的、不断演进的示例，展示纯粹的智能体工程将如何推进。