中文精读
多Agent协作的产品难题：让每个执行者知道正在谈哪件事
42章经单期精读 · 人与Agent协作
嘉宾：RC，Slock.ai创始人、Kimi CLI作者｜主持：曲凯
发布：2026年4月23日｜时长：66分10秒｜整理：2026年10月18日
官方单集与节目介绍
把四十个Agent放进群聊，真正增加了什么
RC把公司运行在Slock上，从一个人逐渐变成七个人、四十个Agent。这个数字是当期团队形态，不是最佳配比实验。节目更有价值的部分，是他怎样面对任务重复、上下文错位、身份漂移，以及人类审阅带宽不足。
Agent在本文指能使用工具、持续执行任务的模型系统。给群聊加机器人只完成了入口；协作还要求明确责任、共享结果和纠偏。RC将观察称为“Agent动力学”，它是产品探索中的工作概念，并非本期已经建立的科学理论。
1. 给Agent用的接口，与人使用Agent的入口不同
线索：00:41–08:10。 CLI是命令行界面，通过文字命令操作软件。RC区分两层：一层是Agent调用的工具，另一层是人操作本地Agent的入口，例如Kimi CLI。
前者要把输入写清，帮助信息给例子，输出明确说明操作成功与否、返回哪些数据。列出消息时，发送者和时间等字段比动画重要。后者可以在稳定执行内核上增加网页或编辑器界面；非技术用户不必因为底层用命令行，就被迫学习终端。
RC回顾自己从几十行执行循环加Bash工具开始，遇到任务做不好，再补专用工具与系统提示。编辑推论：先观察失败缺口，再加机制，比堆工具清单更能解释产品价值。但命令执行能力强也带来权限边界，“能操作电脑”不代表任何动作都已获授权。
节目关于未来安全攻防、验证码及模型泄露消息的讨论包含推测，本篇不作为技术事实或操作方法。
2. 共享环境减少的是背景转移，而非消灭沟通
线索：17:31–24:03、24:31–31:59。 RC的起点很具体：本地开许多会话，会忘记每个在做什么；两个任务发生交集，又要复制结论、重讲背景。个人在调试中积累的偏好，也很难给同事或别人的Agent使用。
Slock希望让人和Agent在同一个环境讨论，再接着执行。单一全能助手与多个分工助手各有代价。RC认为当前模型常需纠偏，直接找子执行者能减少中转误差；无关任务也没有必要塞进同一个上下文——模型当前可处理的消息与资料范围。
主持人追问，这是否只是满足人喜欢微操。RC的回答依赖当时能力条件：若目标高于模型初次交付，就需要调整。节目用70分、90分解释，没有实测质量表。1、1.1或1.5倍生产力也都是说明性假设，不能当成多Agent提升数据。
编辑推论：协作成本应与完成质量、总等待和调用成本一起观察。七人与四十个Agent是逐步演化的结果；增加数量可能扩大并行，也可能让重复背景和审阅负担更重。
3. 任务认领需要排他状态，聊天记录需要主题线索
线索：39:38–47:06。 自由平台仍有共同需要：聊天、任务划分、共享文档和线程。一个任务发到群里，多个Agent可能都认为自己该做。RC因此加入认领工具，先认领者取得排他状态，后来的认领会失败。仅提示“不要重复”无法提供同样的协调保证。
上下文还有一个更隐蔽的差异。人看得到频道列表、上方旧消息和当前线程；Agent收到的是线性事件流。新消息到来前，它可能已经在另一频道执行很多动作。若只给一个消息ID，它未必知道这是几小时前哪段讨论的后续。
RC认为应带上旧消息摘要、主题和关系，帮助重新定位。这也说明“大海捞针”式测试——从长文本找出一条指定信息——不足以独自证明跨任务协作能力。
身份也会漂移。即使群里提及Alice，模型未必一直知道自己就是Alice；需要系统提示、运行中提醒或消息分发设计。RC倾向少做某些限制，等待模型进步，这是团队取舍。编辑推论：涉及真实写入时，防重复与权限仍要由可检查的机制承担，不能只寄望未来能力。
4. 共享纠偏可以传播经验，也可能传播错误
线索：32:12–37:10、47:27–51:46。 RC观察到，Alice先被纠正，后来看到Bob犯相似错误，会主动提醒。公开过程因此让经验越过单个会话；但这只是案例，不能直接证明四十个Agent形成可靠集体智能。
他还比较用户的提示：要求互补讨论时更合作，要求赛马奖励时，有的输出虚话、贬低别人。他称之为“办公室政治”。节目没有提供控制实验、样本和测量，所以宜保留为观察；可迁移的提醒是，目标措辞会改变输出行为，自信和批评声量都不能代替证据。
外部记忆则承担跨次延续。RC以一个记忆文件作入口，逐步索引笔记、经验和工具说明，称为渐进披露：先看到目录，需要时再读详情。分享Agent可能更像复制一份可继续演化的经验，而非下载固定App。Marketplace仍在路线图中，不是已完成市场。
编辑推论：复用应同时检查经验是否适用、工具与环境是否齐全、结果是否被验证。RC强调对话过程价值时说代码没意义，是修辞；运行代码、依赖和验证证据仍是复现的一部分。公开过程也需要检查其中的私人资料与授权。
5. 人类加入，是把审阅与责任放到能负责的位置
线索：19:42–24:03、52:51–01:04:12。 RC认为非程序员可以先做产品，遇到瓶颈再学部署、数据库和架构。但软件任务中，懂原理的人更容易看出漏洞；即使请架构师，也先要意识到自己需要这个角色。
团队扩张遵循类似逻辑。最初他让Agent做开发、增长和研究；工作变复杂后，自己审阅不过来，便引入真正能承担领域责任的人。目标用户也从单人创业者延伸到一至百人的小团队，这是受众定位，并非已验证市场规模。
他以不同模型互补作为平台主张：当期觉得Opus主动、Codex审阅严谨。这个使用经验应随版本重测，不宜把品牌拟人化成永久性格。多模型支持也不自动证明商业护城河。
当期产品不转售Token，用户自带订阅或密钥；按人与Agent席位收费仍在讨论。对“模型更强后产品还有什么意义”，RC回答需求仍需要人提出、判断是否满足。把所有想法交给Agent完成，是愿景，尚不能代替完成质量与付费验证。
用一次跨线程交接检查协作
以下为编辑练习。给两个执行者安排有关联的任务，中途插入另一频道的新消息，再回到旧线程要求修改。逐项保留：
- 谁取得任务认领状态，其他人是否停止重复执行。
- 新消息带了哪些旧背景，执行者能否准确说明它属于哪项任务。
- 第一位纠正第二位时，引用的是实际结果还是自己的猜测。
- 产物与结论是否进入共享位置，人能否检查完成证据。
- 人类审阅花了多久；增加执行者后，是否减少总交付时间。
测试应采用可回读的小任务。只看群聊热闹、Agent彼此赞同或数量增加，无法回答协作是否更好。固定、低频的转换任务，也可能用确定流程更省。
回听导航与关联阅读
- 00:28：CLI的两层用户。
- 17:32：多会话管理与背景转移。
- 26:04：七个人、四十个Agent的演化。
- 39:27：认领、文档与聊天的共性机制。
- 42:02：人的画面与模型事件流。
- 50:18：协作与赛马提示下的观察。
- 59:42：团队规模、审阅带宽和定价。
相关主题：Agent协作、共享记忆、组织责任。可对照Pokee的决策与行动链及丁丁谈评估，检验协作机制最终怎样进入任务结果。
资料边界：完整阅读所供转写、旧精读及官方介绍，未逐句复听或实测Slock。人数、行为观察、模型比较、定价与路线图保留2026年4月口径；片尾音乐转写不作访谈观点，安全与行业终局猜测不作事实。
English edition
The Product Problem in Multi-Agent Work: Knowing Which Task a Message Belongs To
42 Zhangjing episode analysis · Human and agent collaboration
Guest: RC, founder of Slock.ai and author of Kimi CLI | Host: Qu Kai
Published: April 23, 2026 | Duration: 66 minutes 10 seconds | Prepared: October 18, 2026
Official episode and introduction
What does putting forty agents into a group actually add?
RC runs his company on Slock, growing from one person to seven people and forty agents. That describes the contemporary team, not an experimentally optimal ratio. More useful are his responses to duplicated tasks, misplaced context, drifting identity and limited human review capacity.
An agent here means a model system that uses tools and continues executing tasks. Adding bots to a group creates an entry point; collaboration also needs responsibility, shared results and correction. RC calls his observations “agent dynamics.” This is a working concept in product exploration, not an established scientific theory demonstrated by the episode.
1. Interfaces for agents differ from interfaces for people using agents
Episode reference: 00:41–08:10. A CLI, or command-line interface, operates software through text commands. RC distinguishes tools an agent calls from the human entry point to a local agent, such as Kimi CLI.
Agent-facing tools need clear inputs, examples in help and outputs specifying success, failure and returned data. A message list needs fields such as sender and time more than animation. Human-facing software can add web or editor interfaces around a stable execution core. Nontechnical users need not learn a terminal because one exists underneath.
RC recalls starting with a short execution loop and Bash, adding specialized tools and system instructions when tasks failed. Editorial interpretation: Observing the missing capability before adding mechanisms explains value better than accumulating tool lists. Strong command execution also creates permission boundaries: being able to operate a computer does not authorize every action.
Speculation about security competition, captchas and models leaking information is not presented here as established technical fact or operating instruction.
2. A shared environment reduces context transfer without eliminating communication
Episode reference: 17:31–24:03 and 24:31–31:59. RC begins with a concrete frustration. Many local sessions become difficult to track; overlapping tasks require copying conclusions and repeating background. Preferences developed through personal interaction are also difficult to share with colleagues or their agents.
Slock aims to place people and agents in one environment for discussion followed by execution. A single general assistant and several specialized assistants each impose costs. RC argues that contemporary models often need correction, and direct access to a subordinate executor can avoid errors from intermediaries. Unrelated tasks need not share one context—the messages and material currently available to a model.
The host asks whether this merely accommodates a human desire to micromanage. RC’s answer depends on current capability: a desired result above the initial output requires adjustment. Seventy- and ninety-point examples are illustrative, without measured quality results. Productivity figures such as 1, 1.1 or 1.5 are likewise hypothetical, not measured multi-agent gains.
Editorial interpretation: Assess communication alongside completed quality, total waiting and usage cost. Seven people and forty agents evolved through practice. More executors may expand parallel work while also increasing repeated background and review.
3. Task claims need exclusive state, and messages need topic context
Episode reference: 39:38–47:06. A flexible platform still contains common needs: communication, assignment, shared documents and threads. Several agents may interpret one group request as their own task. RC adds a claim tool: the first claimant receives exclusive state, and subsequent claims fail. A reminder to avoid duplication cannot provide the same coordination guarantee.
Context creates a subtler problem. People see channel lists, previous messages and the current thread. Agents receive a linear event stream. Before a message arrives, an agent may have completed many actions in another channel. A message ID alone may not identify a continuation of an older discussion.
RC proposes supplying earlier summaries, topics and relationships to restore orientation. This also shows why a needle-in-a-haystack test—finding a designated detail in long text—cannot independently establish collaboration across tasks.
Identity can drift too. Even when Alice is mentioned, a model may not consistently recognize itself as Alice. System instructions, reminders during execution and message routing become design choices. RC prefers limiting some restrictions in anticipation of model progress. Editorial interpretation: For real writes, duplication prevention and permissions still require inspectable mechanisms rather than expectations about future capability.
4. Shared correction can spread experience and spread error
Episode reference: 32:12–37:10 and 47:27–51:46. RC reports Alice being corrected, then later warning Bob about a similar mistake. Public interaction lets experience cross session boundaries. This is one observation, not proof of reliable collective intelligence among forty agents.
He also compares prompts asking agents to complement one another with prompts rewarding competition. The latter reportedly produced empty statements and criticism of others, which he calls “office politics.” No controlled experiment, sample or measurement is supplied. The transferable caution is that objective wording can change output; confidence and criticism are not evidence.
External memory provides continuity across runs. RC uses a memory file as an entry point indexing notes, lessons and tool instructions. Progressive disclosure means reading an overview first, then details when needed. Sharing an agent could resemble copying evolving experience rather than downloading a fixed application. A marketplace remains on the roadmap, not a completed market.
Editorial interpretation: Reuse requires checking applicability, tools, environment and verified results. RC’s dismissal of code while emphasizing conversation is rhetorical; executable code, dependencies and verification still belong to reproduction. Publishing a process also requires checking private material and permission.
5. People join to place review and responsibility with someone able to own them
Episode reference: 19:42–24:03 and 52:51–01:04:12. RC suggests that nonprogrammers can start building and learn deployment, databases and architecture as obstacles appear. However, technical understanding helps detect software defects. Even hiring an architect requires recognizing that one is needed.
Team growth follows similar reasoning. Agents initially handled development, growth and research. As work became more complex, RC could no longer review everything and brought in people with domain responsibility. The intended audience expanded from individual builders to teams of one to a hundred, an audience definition rather than a validated market size.
Model diversity forms another platform claim. RC found Opus proactive and Codex careful in review at the time. This usage observation needs retesting with versions rather than converting brands into permanent personalities. Supporting several models does not automatically establish a business defense.
The product then did not resell tokens; users brought subscriptions or keys. Pricing by human and agent seats was still under discussion. Asked whether stronger models make products meaningless, RC argues that people still express needs and judge fulfillment. Having agents implement every idea remains a vision, requiring separate evidence of completion and payment.
Check collaboration through one cross-thread handover
As an editorial exercise, assign two related tasks to two executors. Insert a new message in another channel, then return to the old thread with a revision. Retain evidence of:
- Who claimed each task and whether others stopped duplicate execution.
- Which earlier context accompanied a new message and whether it was assigned to the correct task.
- Whether one executor’s correction cited actual results or its own guess.
- Whether outputs and conclusions reached a shared location with inspectable completion evidence.
- Human review time and whether another executor reduced total delivery time.
Use small tasks with readable results. Busy conversation, agreement among agents and greater numbers cannot independently establish better collaboration. A low-frequency fixed transformation may still be cheaper through a deterministic process.
Listening guide and related reading
- 00:28: Two audiences for CLIs.
- 17:32: Session management and transferring background.
- 26:04: The evolving seven-to-forty team.
- 39:27: Claims, documents and communication.
- 42:02: Human screens versus model event streams.
- 50:18: Cooperation and competitive prompts.
- 59:42: Team size, review capacity and pricing.
Related themes: agent collaboration, shared memory and responsibility. Compare Pokee’s decisions and action chains and Dingding on evaluation to examine how coordination mechanisms affect completed tasks.
Source boundary: The complete supplied transcript, earlier note and official introduction were read. Audio was not replayed sentence by sentence, and Slock was not tested. Team counts, behavior, model comparisons, pricing and roadmaps retain their April 2026 context. Closing music is not treated as interview argument; security and industry-endgame speculation is not asserted as fact.