Agent 不是员工，是函数调用

「我用10个AI员工给我干活赚钱」「一人公司指挥AI团队」「三省六部AI朝廷」，最近看到很多这种内容，配图常常是组织架构图、官员头像或者人物分工表。

这类内容的流量很好。很多几十万以上播放的视频、GitHub星标1万5千+的项目、新浪、36氪连篇报道。

但我想说一句不太招人喜欢的实话：如果你真要用AI干活，按这套思路走是干不好的。

这套思维方式提供的不是工程能力，是当老板的爽感。

先讲清楚为什么这事看起来这么诱人。

把LLM调用包装成「员工」，其实是个心理问题。

第一是控制欲。「我有10个AI员工给我干活」比「我调用subagent完成了任务」更有当老板的感觉。前者你是CEO，后者你只是个写代码的。对很多用户来说，AI时代最大的诱惑不是效率，是地位。

第二是拟人化本能。AI长得像人，会说话、会推理、会道歉，大脑就默认按管理人的方式管他：分岗位、定职责、画组织架构图。这是几千年演化下来的社交本能，骗过自己很容易。

第三是自媒体的流量逻辑。「我有一群AI员工」是个钩子，一秒钟让人想点开；「我学会了用subagent」不是，只会让人一秒钟滑走。

这种思维最极致的落地形态，是号称用中国1400年的历史制度来管理AI的一个项目。这个项目用了720行Python写的「朝堂议政」引擎，给10个参朝官员每人配一份完整人设：emoji头像、品级标签（「正一品·中书省」「正二品·礼部」）、性格描述、固定口头禅。中书令爱用「臣以为需从三方面考量」，兵部尚书爱用「末将建议立即执行兵贵神速」，户部尚书张口闭口算预算。

议政里还有一颗「命运骰子」，可以随机触发16个古装剧剧情：「八百里加急边疆战报」「钦天监急报天象异常」「太后懿旨」「皇帝做了一个意味深长的梦」。每次议政LLM还要给每位官员打6种情绪标签（中性 / 自信 / 担忧 / 沉思 等），官员发言可以包动作描写，比如「拱手施礼」。

加上前端774行React、12个agent共1132行system prompt，2600多行代码，专门为了让模型像古代朝臣那样讲话。

这没什么不对。人对权力的本能想象很正常，看古装剧也舒服。我也不反对作者这样做，很多时候，把产品做得好玩是特别重要的，我非常理解和赞同。

但是对于想用AI做正事的人来说，不能把它当成正确的工程方法。

AI时代真正的工程问题，不是「我有几个AI员工」，是「我手上的这个任务，该怎么打包成上下文喂给agent，让他干完返回一个干净的结果」。

换一个核心论点：

这句话展开有三层。

你给agent的不是「岗位描述」，不是「你是一个资深架构师」，而是一个打包好的工作上下文：这次任务要做什么、需要哪些材料、判断标准是什么、返回格式是什么。一份打包好的上下文，本身就承担了「岗位」全部的有用部分。

对AI来说，一个干净的上下文极其关键。举个例子，你和AI反复修改一篇文章，改了很多轮之后让他评价这篇文章，他大概率会说「还不错」，因为上下文里全是你们一起反复打磨的努力痕迹。但如果你这时候新开一个子agent，只把这篇文章的正文给他，让他评价，他没看见前面那些修改的辛苦，可能会表达这篇文章就是一坨屎。

往往后者才是你真正需要的判断。

Agent干完就把结果交回主线程，不持续在线、不持续占用注意力、不持续吃token。一次调用一个结果。

举个例子，你在开发一款软件，需要把里面200行文档翻译成英文。这时候你拉一个subagent去翻译，回到主线程，主线程只需要知道「翻译完成」这一句话，不需要把这200行内容加载进来。否则主线程的上下文会被这些细节淹没，对真正重要的事情就分心了。

而翻译那个agent翻译完了，就没必要继续在线，也不需要占用任何资源。用一个比喻的话：agent不是你忠实的朝臣，是你用完即弃的棋子。

主线程是唯一的决策中枢。Agent串行被调用、串行返回、由主线程决定下一步，而不是多个agent平行协商、互相投票、然后主线程从一团乱麻里收拾残局。

真正需要控制的是上下文的隔离和流向，不是一群朝臣叽叽喳喳妄议朝政。

这套结构对应一个具体的画面。

你写完一段代码，需要agent帮你跑一遍测试。脑子里浮现的画面不应该是「派一个测试工程师」。

应该是这样：

你和他的关系不是老板和员工，是函数调用关系。

这才是真正的「上下文隔离」。它解决的核心问题不是「分工」，是保持主线程的判断力清醒。

前面讲的「上下文隔离」「用完即弃」是设agent的两条常见理由。还有一条同样重要、但更容易被忽略的：简单事用便宜模型，复杂判断用SOTA模型。

这才是真正意义上的「分工」：按模型能力档位分，不是按人设分。

举个具体场景。批量整理几百个文件的元信息，这种任务用Haiku完全够，省的钱可能就是几十倍。但让agent判断「这份产品需求有没有逻辑漏洞」，这种活值得花Opus。

如果你脑子里在想「我需要一个PM agent + 一个开发agent + 一个测试agent」，你已经在用错的维度切问题了。

正确的维度是：这个任务该用什么上下文、调几次、用哪个档位的模型。

正面观点讲清楚之后，再回头再看「赛博朝廷」项目，就比较容易判断了。

12个agent的默认配置都指向同一个模型。同一个模型对自己讲话不会产生真正的多视角。多视角的前提是不同的底层认知，不是不同的角色扮演。古代门下省能制衡中书省，是因为门下和中书代表不同的政治派系、不同的知识传统、不同的利益结构；同一个AI戴两顶帽子，没有这种结构性差异。

README头版写着「门下省专职审核·可封驳」，听上去像1300年前的真制度。打开代码，写着「最多3轮，第3轮强制通过」。

从工程角度，3轮放行也不算坏，可以避免一直不放行卡死。但审核本身没有意义，加上最多三轮就可放行，得到的是一个「看起来有审核」的视觉效果。这个过程要花费6次LLM调用，有这些token，完全不如让单agent做更多迭代反思。

同一个项目的全局规则里有这样一条：

多agent系统要专门防御自己内部的通信，等于承认agent之间本质上就不可信。

说明流程本身不可靠。中书省的prompt里专门写着：

我在之前那篇Harness完全指南里写过一个原则：能用函数的就不要用自然语言。函数一定会被执行，自然语言不一定。

事件总线、Redis队列、Postgres审计、WebSocket接口、看板轮询、命令行同步工具：所有这些都不是为了把活干好，是因为架构一开始就错了，agent之间没有共享上下文，要靠外置系统强行同步状态。

那个项目里12个agent的system prompt加起来1132行，光「kanban_update」这一个看板同步命令就在12个prompt里重复出现142次，每次agent调用都要把这些重复内容打到模型里一次，纯属花钱买「组织感」。

我并不是说这个项目做得不好。我觉得每一个能火的项目都有它值得学习的地方，如果这个项目能让更多人因为它了解AI、愿意开始用AI，它的作用也是非常正向的。

但这更多是一个好玩的游戏，不能当成提高生产力的方法。

我在很早的视频里就反对用角色扮演给AI分工。之前公众号那篇Harness文章里也提到过，子智能体的价值不是分工。

但你可能会问：凭什么我说的就一定对？

这其实不是我一个人的判断，是跨阵营的共识。

表达很直接：

文章里给的三条核心原则是：简单、透明、工具设计精心。没有一条提到「按角色配agent」。

用一个让人记得住的例子讲清楚按角色拆agent为什么会失败：

他们的默认推荐是「单线程的线性agent」（single-threaded linear agent），能用一根主线就用一根。整篇文章里他们点名表扬的是Claude Code的subagent设计：「subagent只回答窄问题，从不与主agent并行」。

Swarm是OpenAI曾经的实验/教育框架（现已被Agents SDK取代），在README里讲得很白，整个API只有两个原语：Agent和「移交」（handoff），agent可以随时把对话移交给另一个agent。Swarm的设计哲学是「调用之间不保留状态」（stateless between calls）：不需要事件总线，不需要审计数据库，每一次移交把上下文显式传过去。和「赛博朝廷」那种带事件总线、看板异步同步的架构刚好相反。

给agent下过一个极简定义：

注意他用的词：「循环」（loop），不是「团队」（team）；「一个目标」（a goal），不是「组织架构图」（org chart）。

当然，并不是不能用多agent。Anthropic自己做深度调研系统时就用了多agent，性能提升超过90%，但这并不是反例。

仔细看那篇案例就会发现，Anthropic的多agent不是按角色拆（没有「PM agent + 开发agent + QA agent」），是按探索方向拆：同一种agent，同时去查不同的子空间，结果汇总到主线程。这恰好是「按上下文窄化拆」的另一种形态。真正的分界线从来不是「多个agent还是单个agent」，是「按上下文拆，还是按角色拆」。

把这条加上之后，Anthropic、Cognition、OpenAI、独立工程师，四个不同立场的来源，落在同一个结论上：

我认为现在AI的使用确实是科学和玄学（或者说是哲学）的结合。

Claude Code团队的Thariq Shihipar在最近一次访谈里说，他写prompt喜欢加一句：「Claude，去犯错吧！启动恋爱脑，做点糟糕的决定」（原文：Make mistakes Claude. Fall in love. Make some bad decisions.）。主持人Claire Vo自己prompt结尾常用「我信任你，我看好你」（原文：I trust you. I believe in you.）。

这他妈绝对是玄学。

Anthropic在2026年4月发了一篇研究《Emotion Concepts and their Function in a Large Language Model》：找到了Claude内部对应171种情绪概念的「情绪向量」（emotion vectors）。研究证明，用户输入里的情绪强度确实会激活模型内部不同的「特征」（features），进而影响行为。这是「机制可解释性」（mechanistic interpretability）这条线扎实的工程进展。

但研究没有证明「对Claude友善 → 输出更好」这件事。Thariq自己在访谈里也明说：

这说明他自己既懂科学，又用玄学。他保持友善，只是因为「我认为一个友善的世界会运行得更好」。

这一段非常关键。请注意他们的认知结构：

反观「AI团队」「赛博朝廷」这套思维，它是玄学，而绝非科学。把组织管理本能直接当成工程方法，把权力幻想直接当成架构设计。

科学打底，玄学才有位置。反过来不行。

下次有人问你「你有几个AI员工」？

如果你想装技术，你可以语速极快地告诉他：我没有AI员工。我有一个主线程在思考，和一些上下文包随手丢给subagent去跑。Agent用完就销毁。需要的时候有上百个并发，不需要的时候一个都没有。

如果你想装深沉，你可以做沉思状告诉他：我考虑的不是组织行为，是上下文的形状。

如果你想装高冷，你可以冷漠地告诉他：我和agent的关系，不是老板和员工，是函数调用。

我觉得这三个回答，都比「我有一个AI马云帮我决策，有一个AI巴菲特帮我投资，有一个AI乔布斯帮我做产品」更装也更高级。

关键是，这才是正确的打开方式。这是科学。

每一次你愿意从「我有N个AI员工」切到「我手上有几种上下文该怎么打包」，你和AI协作的真实质量就会上一档。

然后再去和AI聊「恋爱吧，犯点错」，那是你的哲学，你可以随便玩，但你的工程质量有科学打底。