「日志才是产品」
多智能体演示有一个共同的通病：看起来热闹，但价值有限。几个智能体轮流发言、互相汇报，观众看到的是对话，而不是产物。演示结束后，很难回答三个基本问题——最终交付了什么、这些内容是谁验证的、如果结果不对能不能追回去。
一个 MIT 许可的开源项目 Agent Team 提出了相反的取舍。作者的原话是：多数多智能体演示里，日志才是产品，工作反而是次要的；而他想要的是反过来——一次请求进去，真实文件出来，并且留下可以事后审计的轨迹。项目基于本地优先的运行时，通过 GitHub 仓库 FORIFOR/Multibot 开源。
需要说明的是，目前公开的是作者自己的一次运行记录与四轮迭代经验，缺少第三方复现与规模化验证，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。因此本文只讨论它已经公开的机制与设计取舍。
四个角色与一次真实运行
项目把团队分成四个角色。Master 负责规划，决定这次任务需要几个子任务、分别交给谁；Researcher 负责查证；Builder 负责产出；Reviewer 负责验证。角色之间的分工不是装饰，它决定了每个智能体能看到什么、能做什么。
作者公开了一次可复现的运行。请求是：根据一段产品描述，做一个日文落地页和三份社交文案，缺失信息要记录假设，发布前停下，由 Reviewer 验证。结果是：Master 选择了「一个 Builder 任务加一个 Reviewer 任务」，跳过了 Researcher；记录了 8 条假设，明确不编造价格与数字，只使用占位链接；最终产出四份交付物——单文件落地页、文案文件、交接文档与最终报告；10 项程序化检查全部通过；Reviewer 给出 6 分制的满分评价，并额外提出 4 条可选发现。整次运行消耗 39 个模型回合、35 次工具调用，按标价折算约 1.66 美元，耗时约 18 分 37 秒。
这些数字本身不构成基准——一次运行说明不了什么，作者自己也这么讲。但「8 条假设」「只使用占位链接」「发布前停下」这几个约束值得注意：它们说明系统的设计目标是「不编造」，而不是「尽可能完成任务」。这个优先级排序在多智能体项目里并不常见。
只有真正送达的消息才唤醒模型
项目在消息机制上有一个明确的判断：只有真正被投递到另一个智能体邮箱的消息，才会作为事件记录并唤醒对方；纯粹的确认回执不会唤醒任何模型。这个设计看似细节，实际决定了成本结构——如果每一条礼貌性的回应都要启动一次模型调用，多智能体系统的开销会迅速失控。
另一处值得记录的是它对「模型自述」的不信任。运行成本与用量从命令行工具的 JSON 结果中读取，实际使用的模型从运行记录里取，而不是采信模型自己声称用了什么。这个做法在审计语境下是必要的：如果系统要证明「这次运行确实由某个模型完成」，就不能把证据建立在被审计对象的自述上。
把验证绑定到产物版本
项目强调验证记录是绑定到每个产物版本的。也就是说，某个文件通过了哪些检查，是与那个具体版本关联的，而不是与「这次任务」笼统关联。这一点对真实工程很重要：如果产物在验证之后又被修改，此前的验证结论就不应继续生效，而版本绑定让这种失效可以被自动识别。
与之配套的是「交接文档」这个产物。它记录的不是最终方案是什么，而是过程中的判断依据、尝试过的路径与放弃的理由。这类信息在多人协作里通常以「前任离职前三天赶出来的交接文档」形式存在，质量参差；把它变成系统自动产出的一等产物，是一个务实的设计。
本地优先与可替换的模型后端
运行时采用本地优先架构，默认让每一次智能体会话都通过本地命令行工具执行，团队自有的工具以 MCP 形式通过一个小型代理暴露给会话，策略、预算与事件日志与走 API 的路径保持一致。每个智能体可以独立配置模型后端：官方 API、任意兼容接口，或本地模型。
技术栈上，后端是 Python、FastAPI 与 SQLite，事件以追加方式存储并通过流式接口推送；前端是 React 与 TypeScript；Builder 执行的命令被限制在 macOS 沙箱内，不允许联网，且只能写入任务工作区。这套组合的选择偏向「可审计」而非「高性能」：追加式事件日志与流式推送，天然适合事后回放与追责。
四个版本的迭代说明了什么
作者提到一共跑了四轮。其中一轮完成度不足，暴露了一个具体缺陷：当一个 Reviewer 同时验证两个任务时，只有最后一个判定被记录。这个缺陷随后被修复，另外两轮则撞上了限制并做了参数调整。
这段记录比结果更有价值。它说明即便是刻意强调审计的系统，也会出现「记录丢失」这类问题——而这类问题恰恰是审计能力最需要防范的。作者把失败轮次与修复过程一并公开，也让这份材料更接近工程记录，而不是宣传材料。
中立思辨
需要辩证看待几件事。其一，单次运行不是基准，1.66 美元是标价折算而非实付，18 分钟是一次任务而非稳定吞吐，这些数字不能用来与其他系统做能力比较。其二，本地模型后端的能力上限直接决定团队协作的上限，用弱模型驱动的多角色协作可能放大错误而非纠正错误。其三，日志的完整性依赖「所有工具调用都经过统一网关」这个前提，一旦有工具绕开网关直接执行，审计链就会出现缺口，而这类绕行在实际使用中并不罕见。其四，多角色分工增加了调用次数与延迟，在任务简单时它的成本高于单智能体，适用边界需要用户自己判断。其五，项目规模仍小，长期维护与社区活跃度存在不确定性，把关键流程建立在单人主导的早期项目上有实际风险。其六，「不信任模型自述、只采信外部记录」这个原则值得推广，但它也意味着系统需要为每类信息都建立外部可验证来源，工程量不小，小型项目往往难以完整实现。
趋势研判
短期看，多智能体项目的评价标准会从「角色设计得多精巧」转向「产物与验证是否可追溯」，因为前者容易演示，后者才决定能不能上生产；中期看，如果审计轨迹成为标配，多智能体系统与合规、审计工具的接口会成为新的集成点；长期看，真正稀缺的可能不是能协作的智能体数量，而是能证明「这次协作是可信的」那套记录机制——当智能体开始代表企业执行有后果的动作，「可追溯」会从加分项变成入场要求。
对正在尝试多智能体的团队来说，一个务实的建议是把评价重点放在交付物与验证记录上：先问清楚「这次运行产出了什么文件、哪些检查通过了、失败的那一轮留下了什么」，再去看角色设计是否精巧。前者决定了系统能不能被信任，后者只决定了演示好不好看。