这两天我看到一句吐槽,实在太准了:现在不是缺 Agent,是缺活儿给 Agent 干。
原话来自 Zara Zhang 的一条动态: https://x.com/zarazhangrui/status/2046662237306421608
我第一眼看到就笑了。不是因为它夸张,而是因为它太像现实。
为了避免正文里只有超链接文字、预览时看不出原始出处,我把这篇文章最关键的引用原文链接先单独列在这里:
- Zara Zhang 原帖:https://x.com/zarazhangrui/status/2046662237306421608
- OpenAI,Workspace Agents in ChatGPT:https://openai.com/index/introducing-workspace-agents-in-chatgpt/
- Microsoft,Bring your own Agent to MS Teams:https://microsoft.github.io/teams-sdk/blog/bring-your-agent-to-teams/
- Zed,Parallel agents:https://zed.dev/blog/parallel-agents
- Every,We Gave Every Employee an AI Agent. Here’s What Happened.:https://www.youtube.com/watch?v=SRlTgIhESjw
最近几个月,Agent 产品像雨后春笋一样往外冒。OpenAI 在讲 Workspace Agents,Microsoft 在推 Bring your own Agent to MS Teams,Zed 直接把 Parallel Agents 塞进 IDE,Every 甚至做了一期很长的分享,标题就叫 We Gave Every Employee an AI Agent. Here’s What Happened.
你看这阵仗,很容易产生一种错觉:好像只要给每个人配几个 Agent,办公室就会立刻进化成半自动公司。
可真把这些工具放进日常工作里,很多团队很快就会发现,问题根本不在“Agent 不够强”,而在另一个更土、也更难看的地方:我们手里的很多工作,压根还没有整理成适合交给 Agent 的形状。
Agent 不少了,甚至已经有点拥挤
现在的市场不是 Agent 稀缺,反而有点供给过剩的味道。
办公套件里有 Agent,IDE 里有 Agent,客服系统里有 Agent,研究工具里有 Agent,代码仓库旁边也站着一排 Agent。开源世界更热闹,几乎每周都能看到新的 harness、新的 orchestration 层、新的多 Agent 编排框架。大家都在讨论怎么让 AI 更像“数字员工”。
热闹当然是热闹,但热闹不等于落地。
很多团队的真实状态,我觉得挺像下面这样:
- 聊天窗口开了很多个
- 自动化流程接了几条
- 知识库、MCP、浏览器插件都配上了
- 会议纪要也能自动总结了
- 结果关键环节还是人在复制、确认、补洞、返工
这就很说明问题。
如果一个团队已经装了很多 Agent,体感却没有明显变轻,那大概率不是因为 Agent 数量还不够,而是因为任务本身没有被拆清楚。
真正缺的,不是 Agent,而是“可交付的工作”
我越来越觉得,Agent 落地最难的一层,从来都不是模型智商,而是任务设计。
很多人会说:
- 帮我跟一下项目
- 帮我整理下客户反馈
- 帮我研究一下这个市场
- 帮我把这个需求往下推进
这些话听起来像任务,实际上更像愿望。
你让一个 Agent 去“跟项目”,它到底要不要读内部文档?要不要翻群聊记录?能不能动 Jira?能不能催人?它是只做信息汇总,还是允许自己判断优先级?这里每往前走一步,背后都牵涉三个很硬的东西:上下文、权限、验收标准。
这三个东西如果不清楚,Agent 就会从“省事工具”秒变“需要盯着的新人”。
所以我现在看一个 Agent 产品,不太先看它号称会多少技能,我更在意另一件事:它到底能不能稳定接住工作。
一个任务想真的交给 Agent,至少得满足三件事:
- 输入明确:它知道去哪里拿信息
- 边界明确:它知道哪些能做,哪些不能碰
- 输出明确:它做完以后,人能很快验收
少一个,都容易翻车。
这波产品更新,其实都在试图回答同一个问题
如果把最近几条新闻放一起看,会发现一个挺有意思的共性:大家表面上在发布新功能,底层其实都在争同一个东西,谁能更自然地把 Agent 塞进真实工作流。
1. Workspace Agents:想吃掉信息型工作
OpenAI 的 Workspace Agents 很明显盯上的是办公室里的信息流转:读文档、查资料、跨应用整理上下文、帮你推进一些知识工作。
这个方向本身没毛病,因为知识工作的确很适合先让 Agent 做信息压缩。但它也最容易暴露问题:信息很多,边界很模糊,责任很难切。
说白了,Workspace Agents 解决的是“能不能帮你做”,但企业真正在意的是“它到底可以看到什么、改什么、做到哪一步必须停”。
这类产品如果想真正进团队,不只是模型回答得像回事,还得把权限模型和回溯机制做得够扎实。不然它越像同事,管理上越像风险点。
2. Teams Agent:想把 Agent 直接塞进组织协作层
Microsoft 的 Bring your own Agent to MS Teams 更有意思。它不是单纯做一个聊天机器人,而是想让 Agent 进入原本就承载协作关系的 Teams。
这件事听起来很顺,实际上门槛也更高。
因为一旦 Agent 进入组织协作层,它就不再只是一个回答问题的工具,而是一个可能参与消息流、任务流、审批流的角色。它说什么、看什么、能触发什么动作,都会比“单人对话”敏感得多。
我对这种方向的判断是:潜力很大,但想跑通,组织侧的权限治理必须先补课。否则很容易出现一种局面,大家嘴上说欢迎 Agent,真到要开权限的时候,全都开始保守。
3. Zed Parallel Agents:把“多 Agent”变成开发现场的生产力实验
Zed 的 Parallel Agents 是我觉得很典型的一类产品思路:不满足于一个 Agent 慢慢干,而是直接上并行,让多个 Agent 同时处理不同子任务。
这思路很诱人。尤其写代码时,谁不想让几个 Agent 同时读仓库、查问题、改不同模块,然后自己最后像导演一样收结果?
但我对“并行 Agent”一直有个保留意见:并行带来的不只是速度,也会带来审核负担。
如果任务边界清楚、模块隔离明确,那并行确实香。可一旦几个 Agent 都在半懂不懂地碰同一块上下文,最后交到你手里的不一定是更高产能,可能只是更多 diff、更多冲突、更多复核时间。
所以 Zed 这类产品真正要证明的,不是“我能同时跑几个 Agent”,而是“我能不能把并行结果收束得足够可控”。
4. Every 的员工 Agent 实验:把幻想拉回现实
Every 那期 We Gave Every Employee an AI Agent. Here’s What Happened. 我觉得价值挺高,不是因为它给出了一个完美答案,而是因为它终于把问题从产品宣传稿拉回现实世界。
“每个员工一个 Agent”这件事,听起来很未来,也很容易让人兴奋。但真实世界里,员工每天碰到的工作并不是规规矩矩、干干净净的一串 API 调用,而是充满了临时判断、语境切换、口头约定、权限边界和责任分工。
一家公司如果真想让每个人身边都站一个 Agent,最后拼的绝不会只是模型能力,而是组织有没有能力回答下面这些问题:
- 什么工作适合交给 Agent
- 什么工作必须人拍板
- Agent 能接入哪些系统
- 出错以后怎么回滚
- 结果由谁验收
- 日志留到什么粒度
这些问题没想清楚,Agent 配得越多,现场越像一群积极但没人带的实习生。
为什么很多团队买了 Agent,还是没觉得轻松
我自己的答案很简单:因为他们买到了执行者,却还没补上调度系统。
这就像公司突然招来五个聪明新人。每个人都反应快、记性好、还很勤奋。听上去当然不错。问题是,如果没人拆任务、没人定标准、没人做验收,那这五个人带来的未必是产能,也可能是新的管理开销。
Agent 也是一样。
很多团队现在真正缺的,不是再来一个更会说话的 Agent,而是三套更朴素、但绕不过去的基础设施。
我觉得下一阶段最重要的,是这三样东西
1. 任务拆解能力
很多组织并不是执行差,而是任务语言太虚。
一个可以交给 Agent 的任务,最好天然包含这些信息:
- 从哪里取资料
- 重点看什么
- 不要碰什么
- 输出成什么格式
- 遇到什么情况必须停下来交给人
这其实已经不是提示词技巧了,而是管理能力。
2. 权限和边界系统
Agent 一旦进入真实工作流,就不只是“能聊天的模型”,而是潜在操作者。
它能不能读内部文档?能不能发消息?能不能改数据库?能不能动代码仓库?能不能直接代表你执行动作?这些问题都不该靠“应该没事吧”来处理。
老实讲,很多团队对 Agent 的顾虑,不是怕它不聪明,而是怕它在不该动手的时候太积极。
3. 验收和回滚机制
这是最容易被忽略的一层。
Agent 做完以后,什么叫完成?谁来验?发现不对怎么撤回?有没有日志?能不能回看它引用了哪些信息、触发了哪些工具、在哪一步做了判断?
没有这些,Agent 更像一个随机性很高的外包,而不是稳稳当当的生产工具。
我最不喜欢的一种说法
就是动不动把问题归结为“用户不会用 Agent”。
这话当然不能说全错,但我确实不太喜欢。
如果一个产品真的成熟,它就应该尽量帮用户把任务讲清楚、把边界框出来、把结果收束好,而不是把一大堆系统复杂度原封不动甩回给用户,然后告诉你:用不好,是你不会描述需求。
这就有点像卖你一支很贵的笔,再顺手教育你写不出好文章是因为文学修养不够。话也许没毛病,但多少有点偷懒。
好产品该做的,是减少组织摩擦,而不是把摩擦包装成学习成本。
最后一句
如果只看发布节奏,你会觉得 AI 行业正在疯狂制造“数字员工”。
但如果往深一层看,今天真正稀缺的,其实是“数字管理学”。
Agent 真的不缺了。缺的是那种被切分过、被授权过、被定义过、最后也能被验收的工作。
谁先把工作重新整理成机器接得住、人也愿意验的形状,谁才更可能吃到下一阶段的红利。至于那些铺天盖地的 Agent 发布,有一部分当然是真进步,另一部分,说难听点,更像气氛组。