UstaWork：让多个AI智能体协作编码的工作流控制平面

当编码不再是难题，治理才是

自主编码智能体最难的部分，恰恰不是让它写代码。UstaWork 的创始人在构建一套让 AI 智能体以团队形式协作的系统时发现：很快，问题就从「如何提示」转移到了别处。

一个单独的编码智能体确实能产出一份像样的补丁。但真实的软件工作并不是这样发生的——有人需要理解问题并制定计划，有人负责实现，还得有人来评审，安全问题有时需要单独审查，最终还要有角色判断这项工作是否真的可以交付。

作者提炼出的最核心原则是：**做工作的智能体，不应该是判断工作好坏的智能体。**这句话听起来简单，却决定了整个系统的设计思路——把 AI 当作工作流中的「工人」，而不是聊天机器人。

把软件开发拆解成一条可编排的流水线

在这套思路下，一个典型的软件工作流被拆成了清晰的阶段：

计划 → 实现 → 代码评审 → 安全评审 → 审批 → 合并

这条流水线并不死板。部分步骤可以并行执行；评审者可以把工作打回重做；人类可以在合并前介入审批，整个流程也可以完全自主运行。换句话说，你想要多少人工审批，就保留多少——从「全程盯着」到「完全放手」之间任意调节。

这种设计直指协作式 AI 的本质痛点：单个模型再强，也缺乏制衡机制。而通过引入独立的评审与审批角色，系统获得了类似人类团队的质量把关能力。

可观测性：你凭什么信任它自动合并

一旦让智能体串联起来跑长流程，一系列新问题就暴露出来。作者列出了他必须回答的几个关键问题：

• 每个智能体做了什么、做了哪些决策？
• 某项工作为什么被拒绝？
• 哪个模型负责了哪一步？
• 当某个智能体失败时发生了什么？
• 能不能信任系统在无人监督下完成合并？

这些问题的本质是可观测性与可追溯性。如果你希望让一套 AI 系统在没有人盯着的情况下把代码合并进主干，就必须先建立起对每一步决策的记录和归因能力。这也是 UstaWork 把自己定位为「控制平面（control plane）」而非单纯编码工具的原因。

可观测性（Observability） 一词源自控制论，在软件工程中通常指通过系统对外暴露的输出（日志、指标、追踪）来推断其内部状态的能力。传统软件的可观测性已经是个挑战，而 AI 智能体系统更复杂：每次模型调用的输入输出都是非结构化文本，决策路径难以像函数调用栈那样精确回溯。

控制平面（Control Plane） 这一概念借自网络工程——在 SDN（软件定义网络）中，控制平面负责决策「流量该往哪走」，而数据平面负责实际转发。套用到 AI 工作流中，控制平面不执行具体任务，而是决定哪个智能体在何时介入、以何种条件将工作传递给下一环节，以及在什么节点触发人工审批。这一架构分离使得治理逻辑与执行逻辑解耦，便于独立调整审批规则而无需改动智能体本身。

上下文即基础设施：成本与效率的博弈

当工作流变长，另一个问题变得尤为突出：上下文会迅速变得昂贵。

最简单的做法是把整段对话和前一个智能体的输出，原封不动地传给下一个模型。这确实能跑通，但会浪费大量 token，最终本身演变成一个扩展性难题。

作者的应对是把上下文也当作基础设施来对待。UstaWork 并不只是机械地在智能体之间传递 AI 输出，而是引入了三种机制：

• 上下文压缩（context compression）：减少需要重复传输的信息量；
• 记忆（memory）：保留有用的历史信息；
• 缓存（caching）：当系统已有所需信息时，避免不必要的模型调用轮次。

其目标不是让智能体「遗忘」，而是在保留有用上下文的同时，避免为同一份信息反复付费。在一个有多个智能体来回评审、交接工作的流程中，这一点至关重要——更好的上下文管理意味着更少的 token、更少的无谓调用轮次，以及显著更低的模型成本。

大语言模型按 token 计费——token 是模型处理文本的基本单位，大致对应半个英文单词或一个中文字符。在多智能体流水线中，每个智能体都需要接收足够的上下文才能完成任务，而「把前一个智能体的完整输出原样传给下一个」会导致上下文长度随流程推进线性膨胀。以一个六步流水线为例，若每步输出约 2000 token，朴素传递方式到最后一步时，单次调用的上下文已超过 10000 token，而其中大量信息对当前步骤并无帮助。

上下文缓存（Context Caching） 是部分模型提供商（如 Anthropic 的 Claude、Google 的 Gemini）提供的功能，允许将重复出现的长文本前缀（如系统提示、代码库摘要）缓存在服务端，后续调用命中缓存时费用大幅降低。这与 CPU 缓存的逻辑类似：避免重复计算已知结果。在代码评审场景中，同一段源代码可能被计划、实现、评审等多个智能体反复读取，缓存能显著降低这部分的重复开销。

从「写更好的代码」到「治理一群AI」

这套实践最终把核心命题从「如何让 AI 写出更好的代码」转变为：如何在不做保姆的前提下治理一群正在工作的 AI，同时让整个系统高效到真的能跑起来？

这正是 UstaWork 的产品定位——一个控制平面，让你用专家型智能体、评审环节、条件判断和审批关卡来搭建工作流。智能体负责做事，工作流则决定谁有资格评判、需要哪些上下文、以及工作能否继续推进。

软件工程是它的第一个应用场景，但作者也表示，他越来越好奇这套模型是否同样适用于其他可委托的工作。目前该产品本周刚上线首个生产版本，仅在美国可用，并提供免费套餐。

一点观察

从 AutoGPT 到各类多智能体框架，行业对「AI 协作」的探索已持续了相当一段时间。UstaWork 的价值主张并不在于某个智能体更聪明，而在于把制衡机制、可观测性和成本控制这三件事产品化。这恰恰反映了当下 agent 工程落地的真实瓶颈：技术 demo 容易，可信、可控、可负担地规模化运行很难。

需要留意的是，本文信息完全来自产品创始人的自述，带有明显的推广性质，缺乏第三方的独立评测与实际使用反馈。其宣称的成本节省与自主可信度，仍有待真实场景验证。