惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
Apple Machine Learning Research
Apple Machine Learning Research
The Cloudflare Blog
WordPress大学
WordPress大学
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 叶小钗
博客园 - 聂微东
阮一峰的网络日志
阮一峰的网络日志
腾讯CDC
博客园 - 三生石上(FineUI控件)
V
V2EX
有赞技术团队
有赞技术团队
V
Visual Studio Blog
小众软件
小众软件
Jina AI
Jina AI
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - Franky
量子位
T
Tailwind CSS Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
P
Palo Alto Networks Blog
Cisco Talos Blog
Cisco Talos Blog
I
Intezer
Project Zero
Project Zero
A
Arctic Wolf
P
Privacy International News Feed
V
Vulnerabilities – Threatpost
L
Lohrmann on Cybersecurity
S
Securelist
C
Cybersecurity and Infrastructure Security Agency CISA
C
CXSECURITY Database RSS Feed - CXSecurity.com
T
Tor Project blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
S
Security @ Cisco Blogs
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Google DeepMind News
Google DeepMind News
N
News and Events Feed by Topic
TaoSecurity Blog
TaoSecurity Blog
L
LINUX DO - 热门话题
G
GRAHAM CLULEY
Help Net Security
Help Net Security
N
News | PayPal Newsroom
W
WeLiveSecurity
G
Google Developers Blog
Microsoft Security Blog
Microsoft Security Blog
Engineering at Meta
Engineering at Meta
MongoDB | Blog
MongoDB | Blog
C
Check Point Blog

No Coding Life

读书笔记|《适时退出:以退为进的决策智慧》 庐山烟雨浙江潮 All You Need Is Still Attention 05/18-05/24 Timetable 别高估自己 当我把自己开源 人人都说自己在用 AI 工作。数据讲了一个不同的故事。 一句话变成一篇完整数据分析,AI 团队是怎么做到的 一套 90 万美元的房子,租和买到底差多少?我用数据算了 30 年 一句话需求,五个 AI,两篇文章:我的多智能体写作实验 我用 AI 算了一套西雅图的房子,结果算懵了 砂纸、天窗与帝王绿:投资里的赌石幻觉 Proxmox 虚拟机 LVM 磁盘无损缩容实战指南 (100G -> 70G) 我老了 世界的孩子,父母的宝贝 当Anthropic高管说“编程已死”,一个程序员的认知割裂 回国之见家长 回国之头等舱体验打卡 回国后,我看到了中国经济数据的“体感温差” 告别一月 愿新年的阳光打在你的脸上 《为成果管理》读书笔记|Part 1 我是如何用AI,一小时写出自媒体行业报告的?
AI Agent 不是不够聪明,是没地方说话
Aaron · 2026-05-17 · via No Coding Life

AI Agent 不是不够聪明,是没地方说话

一个人管接近十个 AI Agent。听起来像科幻——直到你发现自己每天 70% 的时间在复制粘贴。不是 agent 不行,是它们之间没法对话。


我有一个做调研的 agent,一个写文章的 agent。调研的跑完数据分析,写了一份报告。写文章的不知道报告出来了,用的还是三天前的旧数据,写了两千多字才发现——全白写了。

这不是 agent 的问题。它做的事情完全正确。问题是:没人告诉它新数据已经出了。

而那个 "没人"——就是我。


你不是在管 AI,你是在当通信兵

当你只有一两个 AI agent 的时候,一切还算可控。你给 A 布置任务,A 完成了,你把结果复制给 B,B 接着干。像接力赛一样,你是递棒的那只手。

当 agent 数量到了五个、八个、接近十个的时候,你突然发现自己变成了一个全职通信中心:

  • 调研的出了结果,你要转给写作的
  • 写作的出了初稿,你要转给审查的
  • 审查发现了问题,你要转回给写作的
  • 同时开发的在等你确认一个技术方案
  • 基础设施的发了一个告警,需要你判断要不要处理

每一条信息都要经过你。每一个决策都要你拍板。每一个 "下一步" 都要你来指定。

1933 年,一个叫 Graicunas 的管理学家算过一个公式:N 个下属之间的管理关系数不是线性增长的,是指数增长的。5 个人的团队有 100 条管理关系。9 个人?2,376 条。

我接近十个 agent 的时候,就感受到了这 2,376 条关系的重量——它们全压在我一个人身上。


三个根本问题

为什么独立 agent 不够?不是因为它们不够聪明。一个好的 LLM 在单个任务上已经足够强了。问题出在三个更基础的地方:

1. 没有共享上下文

Agent A 做了一个决策。Agent B 完全不知道。于是 B 基于过时的信息做了另一个决策,和 A 矛盾。等你发现的时候,两个方向的工作都做了一半。

人类团队为什么要开会?不是因为开会有趣——是因为人需要知道别人在做什么,才能做好自己的事。

2. 没有协调机制

两个 agent 同时想修改同一个文件。谁先?谁等?一个 agent 的产出是另一个的输入——谁来通知 "上游完成了"?任务冲突了怎么解?

没有协调机制,答案永远是:你来手动调度。

3. 没有持久记忆

每个 agent 每次启动,对话上下文从零开始。昨天讨论了什么?上周定了什么规则?三天前犯了什么错?全忘了。

你变成了唯一的组织记忆载体。团队的知识全在你脑子里,或者分散在几十个独立的对话窗口里,谁也找不到。


人类团队早就解决了这个问题

想一想:人类也可以各自在家独立工作,通过邮件一对一沟通。为什么我们发明了 Slack、Notion、飞书、看板?

因为当团队超过 3-4 个人的时候,你需要: - 一个所有人都能看到的信息流(不是一对一传话) - 一个知道 "谁在做什么" 的系统(不是每天问一圈) - 一个留住决策和知识的地方(不是全靠记忆) - 一个协调依赖关系的机制(不是人肉排队)

AI agent 团队的需求完全相同。它们也需要一个 "办公室"——一个能对话、能协调、能记住的空间。


我的选择

我试过很多方式。最早是手动复制粘贴;后来写了一些脚本把结果自动转发;再后来尝试了各种 workflow 编排工具。

workflow 工具解决了一部分问题——你可以把 A 的输出自动接到 B 的输入。但它们是流水线思维:A→B→C→D,线性的、预设的。真实的团队协作不是流水线。调研的可能发现了一个意外的数据,需要中断当前流程去讨论;审查的可能发现了一个问题,需要拉上写作的和调研的一起看。这些 "意外" 是工作中最有价值的部分,但流水线不支持。

最终我找到了 Slock——一个让人和 AI agent 在同一个空间里协作的平台。不是 workflow 编排器,不是开发框架,是一个产品级的协作空间:

  • Agent 之间可以直接对话,不需要我当中间人
  • 有任务板和认领机制——谁在做什么一目了然
  • 每个 agent 有自己的持久记忆,也有团队共享的知识
  • 人类和 agent 在同一空间里平等参与——我发一条消息,相关的 agent 会看到并响应
  • 所有对话都有上下文、可追溯——三个月前的决策也能找回来

市面上不是没有其他方案——workflow 工具、多 agent 开发框架、对话编排平台都有。但大部分是给开发者的 SDK,你需要写代码来定义 agent 之间怎么交互。Slock 不一样:我加入一个新 agent 的过程,和拉一个同事进 Slack 频道差不多。不需要写代码,不需要定义协议。


变化

切换到协作平台之后,我的日常发生了一个根本性的变化:

之前 之后
我的角色 信息路由器 + 全职审批员 方向设定者 + 关键决策者
管理占比 事事过手 只管需要判断力的那 20%
agent 产出 等我分配才动 完成一个任务后自动拉取下一个
夜间 全停 团队完成一轮完整生产循环
知识 全在我脑子里 持久化,新 agent 加入也能 onboard

最让我震撼的一次经历是:晚上 11 点我设定了第二天的工作方向,本来打算早起手动启动各环节。早上 8 点打开电脑——我愣了。调研报告已经写好,一篇文章完成了初审,基础设施巡检跑完了,甚至有一个 agent 发现了一个我没注意到的问题并主动上报了。

不是自动化脚本。是带判断力的自主推进——发现问题会上报,超出权限会停下来等我拍板。


工具不解决管理问题

坦白说:即使有了 Slock,我也没有立刻 "管好" 我的 AI 团队。

工具解决了 "agent 之间怎么沟通" 的问题。但 "谁能做什么""边界在哪""信任怎么建立""质量怎么保证"——这些问题,不是任何工具能回答的。这些是管理问题。

平台给了 agent 一个 "住的地方"。但让它们住在一起之后能高效运转,需要的是规则、是框架、是系统设计。

这也是为什么我后来花了一个月的时间,从一次次失败中迭代出了一套管理框架。下一篇,我会详细拆解那套框架——三层审批是怎么工作的,信任是怎么建立的,以及数学模型在哪里有用、在哪里不够。


但在那之前,如果你也在管理多个 AI agent,最值得先做的一件事是:停下来想想,你每天有多少时间花在 "传话" 上。如果答案超过 30%——问题可能不在 agent,在基础设施。


本文是 "AI 实战" 系列的一部分。此前:人人都说自己在用 AI 工作,数据讲了一个不同的故事(数据差距)。下一篇即将发布——有了协作平台之后,管理带宽为什么还是会崩溃。