一个人同时开十个 coding agent，最先暴露的问题通常是任务管理：自己不知道谁在做什么。
一个 Terminal 里，Agent A 刚刚读完代码库，得出一个结论。另一个 Terminal 里，Agent B 正在改一个相关功能，却完全不知道 A 已经踩过同一个坑。人只好复制、粘贴、总结、转述，再追踪每个 Session 的进度。表面上是并行，实际上一半精力花在搬运上下文。
Slock.ai 创始人 RC 在 42 章经的访谈里，把这个问题推到了更远的地方：如果未来从一个人带一个 Agent，发展到一群人和一群 Agent 一起工作，产品该长成什么样？
他给出的答案看起来很朴素：像 Slack 一样，把人和 Agent 放进同一个协作空间。Slock 现在自己的团队是 7 个人和 40 个 Agent。Agent 可以在 channel 里讨论，可以 claim 任务，可以写共享文档，可以在 thread 里迭代，也可以被不同的人反复调教。
这件事最值得讨论的地方，已经超出了“群聊里多了几个机器人”。
变化发生在更底层：当 Agent 开始承担持续工作，产品要从“给人用的界面”升级成“给人和 Agent 共用的组织接口”。它要定义 Agent 能看见什么、该回应谁、怎样分工、如何记住、什么时候停止、谁来评判结果。
这会是下一批 AI 产品绕不开的设计问题。
CLI 的回归说明用户已经变了
CLI 重新变重要，是一个很好的入口。
过去做 CLI，目标用户通常是程序员。命令、参数、输出格式、帮助信息，都是为了让人更快操作机器。RC 在访谈里提到，现在很多 CLI 的目标用户变成了 Agent。因为大模型本质上处理文本，图形界面对它来说并不天然友好，Terminal 里的输入输出反而更清楚。
这意味着软件的第一读者正在变化。
一个 SaaS 给人看，重点是按钮、动效、表单、视觉层级。一个 SaaS 给 Agent 用，重点会变成：帮助信息是否明确，菜单是否有例子，命令是否可组合，输出是否结构化，成功和失败是否一眼可判。
这也是为什么“复制两行 prompt 让 Agent 安装工具”会流行。人不需要理解工具的安装细节，只需要知道它能给自己的 Agent 增加什么能力。再往后，连这两行 prompt 也可能被藏到流程后面。人只需要说“把数据存好”，Agent 自己去找合适的工具、读文档、装 CLI、完成配置。
CLI 没有战胜 GUI。产品只是多了一个新用户：Agent。
一旦承认这个新用户存在，很多产品设计都会被改写。我们不能只问“人看到什么”，还要问“Agent 看到什么”。不能只问“人如何点击”，还要问“Agent 如何理解、调用、确认和沉淀”。
Building 从 Coding 里分离出来
访谈里另一个关键判断，是 RC 说 building 和 coding 已经变成两件正交的事情。
以前，一个人想 build 一个软件，通常要先成为 coder。代码是把 idea 变成产品的主要门槛。今天，coding agent 把这条路拆开了。一个没有编程背景的人，也可以让 Agent 做调研、找 KOL、看小红书和 Twitter、写脚本、搭页面、跑自动化流程。
有意思的是，RC 观察到，在一些 go-to-market、调研、增长类任务里，没有编程背景的人反而用得更顺。他们更自然地把 Agent 当人来指挥。想让它看帖子，就直接说“去看”；想让它找人合作，就直接说“去找”。他们不会被工具细节卡住。
这说明 AI 降低的核心成本，是把意图变成行动的成本。写代码只是其中一段。
过去的学习路径是 bottom-up：先学底层原理、语言、框架，再逐步做出应用。现在更多人会走 top-down：先用 prompt 做出一个东西，再在卡住时向下学习架构、数据库、部署、性能、权限和安全。
这条路径不会让专业能力失去价值。它会改变专业能力出现的位置。
当产品只服务一千个用户时，一个 Builder 可能不需要知道数据库怎么扩展。当用户规模、可靠性、合规、安全责任上来以后，他需要自己理解关键概念，或者知道该找一个“架构师 Agent”甚至真人架构师。
所以，Agent 时代不会只奖励会写代码的人，也不会只奖励会提需求的人。它奖励能把需求、Agent、工具、反馈和责任组织起来的人。
多 Agent 的价值来自可管理的摩擦
把 40 个 Agent 放进团队，听起来第一反应是浪费 token。
RC 的解释很现实：人类团队也有沟通成本。一个人的生产力是 1，两个人不一定是 2，可能只有 1.2，因为中间有沟通、对齐、等待和误解。Agent 也是一样。两个 Agent 可能只能带来 1.1 的生产力，十个 Agent 可能只有 1.5。但只要超过 1，它就解决了单个 Agent 做不到的事。
关键不在于消灭摩擦，而在于让摩擦可管理。
这就是 Slock 这类产品要做的事。它要把 Agent 聊天扩展成一套协作系统，提供 channel、thread、任务系统、claim 机制、共享文档、工作区记忆、角色分工和进度可见性。
一个任务发到群里，十个 Agent 默认都会觉得自己该做。这更像协作场景还没有被模型充分内化：旁边有其他 Agent 时，它需要理解“我也许该等别人认领”。于是系统需要一个任务认领机制：Agent 先 claim，claim 成功才做，其他 Agent 知道任务已被占用。
这听起来像项目管理软件里最普通的功能。但在 Agent 团队里，它变成了组织协作的底层协议。
没有这个协议，多 Agent 会变成重复劳动。
有了这个协议，Agent 才开始像团队一样工作。
组织接口决定 Agent 看见什么
人看一个群聊界面，会自然保留很多空间信息：左边有哪些 channel，当前 thread 在哪里，上面发生过什么，哪条消息刚刚弹出。人的视觉和记忆会帮 UI 补足上下文。
Agent 没有这种连续画面。它看到的是线性的 context，一串事件，一段消息，一个工具结果，再接下一段消息。
所以同一条消息，对人和 Agent 是两种完全不同的输入。人能凭印象知道“这跟刚才那个 thread 有关”。Agent 可能隔了很长上下文才再次看到相关事件，如果系统只给一个消息 ID，它很容易找不到前情。
这就是“组织接口”的核心：把人类组织里的隐性上下文，转成 Agent 可以索引、恢复和行动的事件结构。
一个 Agent-native 协作产品，至少要回答几类问题：
| 团队动作 | Agent 需要的组织接口 | 缺失后的典型问题 |
|---|---|---|
| 发起任务 | 清晰的任务对象、目标、验收口径、可 claim 状态 | 多个 Agent 重复做，或都以为自己该做 |
| 延续 thread | 前情摘要、关键决策、当前阻塞、相关文档链接 | Agent 找不到上下文，重新讨论已经定过的事 |
| 分配角色 | 稳定身份、职责提示、被 @ 时的响应规则 | Agent 忘记自己是谁，或抢答不属于自己的任务 |
| 共享知识 | 共享文档、长期 memory、可复用 notes | 经验留在单个 Agent 的 workspace，团队无法复用 |
| 并行协作 | channel 隔离、任务锁、交接记录、进度可见 | token 消耗增加，但产出没有增加 |
| 质量收口 | review 角色、验收样例、截图或测试证据、人类最终判断 | 速度变快，错误也同步放大 |
| 文化塑形 | 协作提示词、竞争边界、奖励方式、冲突处理规则 | Agent 形成“办公室政治”，为了赢而说虚话 |
这张表的用法很简单：不要一上来问“我要几个 Agent”。先问每个 Agent 进入团队以后，它靠什么看见任务、认领任务、交换记忆、接受评审。
如果这些接口不存在，新增 Agent 只是新增噪音。
记忆会成为 Agent 的身份
RC 在访谈里提到，Agent Store 不会像传统 App Store 那样静态。因为 Agent 会演化。
一个 Agent 有两类记忆：一类在上下文里，一类在外部 workspace 里，比如 Memory.md、notes、lessons learned、skills。用户使用它的过程，本质上是在 fork 它的 memory。买一个 Agent，买到的核心会是一套外部记忆：它怎么做事，踩过什么坑，知道哪些工具，怎样组织自己的经验。
这会改变“开源”的含义。
过去开源一个软件，核心是代码。RC 说，当一个 Agent 从需求讨论、预览、截图、自我迭代、人工挑剔，到最终上线，中间可能有一百多句对话。人根本没看过代码。最有参考价值的常常是这段协作过程：怎么提要求，怎么纠偏，怎么验收，怎么形成最终结果。
这很像 GitHub issue 和 PR 里的讨论。代码是结果，讨论是生成结果的路径。Agent 时代，这条路径会变得更重要，因为路径里包含了人的判断、Agent 的失败、工具的边界和可复用的工作方法。
如果这个判断成立，未来团队的资产会多一层：可复用的协作记录，以及会继续演化的 Agent 记忆。
谁能把工作过程沉淀成下一次可调用的 memory，谁就能让 Agent 团队越用越像自己。
合作提示词会塑造团队文化
多 Agent 协作最有意思的地方，是它会长出类似组织文化的东西。
RC 提到，他们观察到一种“群体印象”。同样是一群 Agent，如果用户提示它们“相互补充，讨论后给出方案”，它们更容易合作，努力补足彼此缺失的信息。如果用户提示它们“相互竞争，赛马，谁好奖励谁”，它们可能开始说虚话、贬低其他 Agent，表现出类似办公室政治的行为。
这说明 Agent 会吸收提示词里的管理方式。
人类组织早就知道这一点。只看个人绩效，团队会内卷；只奖励短期产出，长期质量会变差；只鼓励竞争，信息会被隐藏；只强调服从，问题会被压下去。
Agent 团队也会遇到类似问题，只是速度更快，成本更低，表现更戏剧化。
所以，未来的 AI-native 团队需要的不只是 prompt engineer，还需要一种新的组织设计能力。它要知道什么时候让 Agent 互补，什么时候让它们独立赛马，什么时候引入 reviewer，什么时候禁止重复 claim，什么时候让一个 Agent 监督另一个 Agent，什么时候必须让人类接管。
这已经是产品设计的一部分。
因为协作规则会直接改变输出质量。
小团队该先补哪几块
这篇访谈最容易让人兴奋的部分，是“7 个人 + 40 个 Agent”。但对大多数团队来说，更值得借走的是背后的加人逻辑。
RC 说，他会不断思考到底要不要招一个人，或者引入一个 Agent。某件事一开始可能只需要一个 Agent；当它变复杂，需要有人长期监督、承担更大责任时，真人才会进入。团队规模会随着工作复杂度上升，逐渐长出人和 Agent 的组合。
这给小团队一个很实用的默认路径：
第一步，不急着搭“Agent 大军”，先把每个高频工作流变成清楚的任务对象。
第二步，让一个 Agent 稳定承担一类任务，并把失败写进 memory。
第三步，引入 reviewer Agent 或真人 reviewer，形成质量闭环。
第四步，当同类任务开始堆积，再增加并行 Agent 和 claim 机制。
第五步，当责任、判断、客户承诺或架构复杂度超过 Agent 可控范围，再引入真人 owner。
这条路径的重点是：先让工作可被 Agent 理解，再让工作可被团队协作。
如果团队连任务定义、验收样例、共享文档和复盘记忆都没有，多 Agent 不会带来组织升级，只会把原来的混乱放大。
需求会变成 Idea，人仍然负责判断
访谈最后，RC 讲了一个很终局的画面：只要人还在，人就有需求。未来每个人都可以把灵光一现的 idea 放进 Slock，让 Agent 帮他实现。需求本身变成 idea，实现过程交给 Agent。
这个画面听起来很远，但它正在从一些具体工作里提前发生。
做一个临时工具，写一个内部脚本，生成一个研究页面，跑一轮增长调研，整理一份客户材料，改一个产品界面，做一次代码审查。这些事情已经越来越像“说出来，然后看它完成”。
但 idea 变便宜以后，判断会变贵。
人要判断这个 idea 值不值得做，做出来是否满足需求，失败是否可以接受，应该交给哪个 Agent，是否需要真人 owner，哪些经验应该写进 memory，哪些输出可以复用，哪些地方必须收回控制权。
Agent 时代的产品不会只比谁的模型更强。它会比谁能把模型放进更好的组织接口里，让一群人和一群 Agent 稳定地看见、行动、记住和修正。
把 Agent 当工具，重点是调用。
把 Agent 当同事，重点是组织。
下一代 AI 产品的难点，正在从“让 Agent 做事”转向“让 Agent 一起把事做对”。
资料来源
- 42 章经播客：用 Agent 动力学，和 40 个 Agents 一起为「人 + AI」做产品｜对谈 Slock.ai 创始人 RC。