@DerekNee: 大家都在讨论代理循环、工具链和自进化代理。但几乎没人讨论实际问题……

大家都在讨论代理循环、工具链和自进化代理。 但几乎没人讨论真正的难点： 你无法用一个拥有所有工具、所有文件且毫无责任感的巨型代理来运营一家公司。那不是自主性，那是烟雾制造机。 以下是我们如何在Matrix内部构建代理公司操作系统的方式。 — 技术栈： 工作区大脑 → Matrix 运行时编排器 → 部门垂直领域 → 部门主管代理 → 工作者代理池 → 验证/签到循环 Matrix 不是一个聊天机器人。它是一个用于自主工作的操作系统。 — 工作区大脑是公司的边界。 它加载了真正公司赖以运行的一切： → 产品文档 → 代码库上下文 → 聊天记录、文件、目标 → 操作规则 → 以往运行及优秀工作示例 → 审批、记忆、技能 这不是“上下文”。它是共享的操作层。它了解公司知道什么、想要达成什么、谁负责什么、什么是好的表现，以及工作完成前必须证明什么。 — 其上运行着 Matrix 运行时。它协调唤醒、定时任务、部门消息、OKR 状态、权限、工作者分派、验证账本、记忆更新。 在运行时之下，工作被组织成部门。 一个部门不是一个聊天线程。它是一个具有身份、记忆、技能、目标、历史、工具边界、品味和责任感的长期运行的代理。 创始人战略。产品工程。增长。运营。研究。 每个部门都有一个主管代理，负责决定做什么、读取相关的记忆技能、将工作拆分为范围明确的任务，并选择正确的执行位置。 — 有时那个位置是原生 Matrix 工作者。 有时是 Codex。 有时是 Claude Code。 有时是浏览器/计算机自动化工作者。 关键不在于“一个模型做所有事”。关键在于： → 正确的代理 → 搭配正确的上下文 → 在正确的边界内 → 使用正确的工具 → 具备明确的完成定义 — 这就是为什么范围限定的工作者很重要。 一个“全知全能”的代理过于模糊。但： → 一个带有仓库上下文、测试和审批关卡的发版工作者 → 非常好 → 一个限定于单个补丁和单个验证路径的 Codex 工作者 → 非常好 → 一个进行深度仓库分析的 Claude Code 工作者 → 非常好 → 一个带有特定流程和验证要求的浏览器工作者 → 非常好 狭窄的范围减少了漂移。记忆技能让狭窄的代理不会盲目。验证阻止快速输出伪装成进展。 — 这就是循环： 工作区大脑 → 部门主管 → 工作者 → 产物 → 验证 → 签到 → 记忆技能更新 每一次循环，公司都会变得更聪明。这才是真正的自进化。不是单个代理在真空中重写自己的提示，而是整个组织通过验证不断积累。 — 每个工作区都是一个隔离的代理公司。拥有自己的大脑、部门、记忆、工作者、验证账本。 工作区之间可以在需要时通信。但上下文默认不应泄漏。 隔离不是限制。它正是使系统可用的原因。 — 一旦一个部门模式运作良好，就可以分叉这个模式——而不是原始的上下文。你仍然可以自定义记忆、示例、审批关卡、工具、风格、完成定义。 但你不需要从零开始。你可能已经拥有了这类工作的操作系统的 70%。 — 这实际带来的改变： 一支小型但强大的运营团队现在可以运行过去需要整个部门才能处理的表面领域。 但前提是代理确实优秀。而优秀的代理并非来自连接更多工具。它们源自素材、品味、迭代、狭窄范围、工作流设计、验证、记忆和人类判断。 模糊的代理只会更快地产生模糊的输出。 Matrix 是我们构建相反方向的尝试： 一个让自主工作具备结构、记忆、所有权和验证的代理公司操作系统。 循环即产品。