@AxtonLiu: https://x.com/AxtonLiu/status/2073791557547794579

X AI KOLs Timeline 工具

摘要

本文讨论了Agent OS的概念,强调通过分工将任务拆解为多个工位(抓取、提炼、核查、确认),每个工位由独立的Agent负责,以实现可控的自动化。作者通过消化浏览器标签的例子,展示了如何通过分工隔离上下文、责任和风险,确保AI输出的准确性和可靠性。

https://t.co/QLJR7Eqno8
查看原文
查看缓存全文

缓存时间: 2026/07/06 10:09

Agent OS 的第一课:会分工,才会用 Agent

Agent OS 不是多建几个 Agent,也不是让一个万能 AI 接管所有事情。它更像一套个人工作控制层:从真实目标开始,把任务拆成工位,给每个工位分配上下文和验收标准,让核查者独立于生产者,让高风险动作停在“待确认”,最后把经验沉淀成可复用资产。

先说一个判断。

现在这些 AI 工具,Codex、Claude、ChatGPT,不会一直停在一个聊天框或者终端里,让你一句一句地问。这只是过渡形态。它们真正的终局,是变成一套 Agent OS:一个你能往里派活、能让一队 Agent 分工去干、结果再回到你这里验收和沉淀的操作系统。

这不是远景。我自己已经在用一套,管着我的 Agent 家族和七十多个 Skill。

但今天我不跟你空谈这个概念。我想用一件你可能每天都在烦的小事,带你看这套系统最底层的那条准则。

就两个字:分工

那件小事是这样的:你的浏览器是不是开着几十个标签,稍后读里还躺着几百篇文章?存的时候想着“回头一定看”,结果再也没回去过。

我以前也这样。后来我用一套分工,把这一堆积压,一个下午消化成一沓真正能用的笔记。关键不在于我用了多强的模型,而在于我没有把这件事丢给一个 AI 让它从头干到尾。

我把它拆成了几个工位,每个工位配一个 Agent:谁去抓,谁来提炼,谁负责核查,谁最后拍板。

这就是搭你自己那套 Agent OS 的第一课,也是这篇文章想说清楚的唯一一件事。

先排工位,再配 Agent

大多数人的顺序是反的。

他们会先问:哪个 AI 最强?哪个模型最聪明?哪个 Agent 最万能?然后把整件事一股脑塞给它。

你是研究员,你是写作者,你是事实核查员,你是发布助理,你还要负责整理知识库。最后请你把这件事从头到尾干完。

这听起来省事,实际很危险。

因为你把三件事混在了一起:

  • 上下文混在一起

  • 责任混在一起

  • 风险混在一起

写笔记的 Agent 如果同时负责核查,它很容易顺着自己的错误往下圆。负责提炼的 Agent 如果同时负责删除,它会把一个听起来合理的误判直接落地。负责生成内容的 Agent 如果还能自动发布,它错一次,错误就从草稿变成公开内容。

这不是 AI 笨。

这是组织结构错了。

我现在的习惯是反过来:先不动手,先排工位。

拿“消化一堆标签”这件事来说,我会先拆成四道:

第一,抓取工位。 把稍后读里这一批网页连正文一起读进来,记录标题、网址和正文状态,再做个粗分类:哪些真能学,哪些写法可借鉴,哪些能补到手头的选题,哪些可以直接归档。

第二,提炼工位。 把每页正文提成几条要点,告诉我这页到底值不值得留。

第三,核查工位。 把提炼出来的笔记拿回原文一条条对,看它有没有自己编,尤其是数字、结论和判断。

第四,确认工位。 把前三道的结果汇总成一张待办清单,每条给个建议:删、归档、保留,还是深读。但它只出建议,最后由我一条条拍板。

你看,这里面没有什么玄学。核心就是一个抓,一个提,一个查,最后汇总成提案交给人确认。

但这四个工位一拆,整套系统的性质就变了。

分工不是为了显得高级,而是为了隔离上下文、隔离责任、隔离风险。

提炼的人不能自己核查自己。核查的人不能替你删东西。确认的人只出提案,不自动落地。

这才是 Agent OS 的味道。

一个工位到底怎么定义

我更愿意用“工位”这个词,而不是一上来就讲 agent、runtime、orchestration。

因为“工位”天然带着责任边界。

一个工位不是一个模型。一个工位是一组清楚的约定:

  • 它扮演什么角色

  • 它负责什么事

  • 它需要哪些上下文

  • 它怎么算合格

  • 它不能做什么

  • 它产出什么交给下一个工位

你把这些事写清楚,一个工位才成立。至于它背后是 ChatGPT 的一个对话框、Claude Code 的一个 subagent、Codex 的一个 agent,还是未来某个真正系统级的 Agent OS,那只是执行后端。

举个最关键的例子:核查工位。

我会这样定义它:

角色:你是一个笔记核查员。 责任:把提炼工位写的每一条笔记、每个数字、每个结论,拿回原文一条条比对。 上下文:我给你两样东西:要核查的笔记,以及每个网页真正的原文。你不能靠自己的记忆判断,只能依据我给的原文。 验收标准:对得上原文的,标“已核实 + 出处位置”;对不上的,或者原文里根本找不到的,标“可疑 / 原文无依据”,最后给我一张表。

难的从来不是语法,是把这几件事想清楚。

而核查工位还有一条铁律:不能让写笔记的那个工位自己查自己。

它自己查自己,盲区是一样的。它看不出自己刚才脑补了什么,等于让一个人审自己的卷子。所以核查必须是另一个 Agent,有它自己独立的上下文,看不到提炼那一步是怎么脑补的,想包庇自己都做不到。

而且必须给它真实原文。

这一条,等下你会看到它救了我一回。

用一堆浏览器标签做例子

为了不暴露我真实的标签库,我用七个中立、公开的网页演示:几篇技术博客、一个 YouTube 演讲、一条推文串。数量比我实际跑的少,但分工和判断一模一样。

先是抓取。

这里有个讲究:网页正文,我不让 AI 现去抓。

你让它直接抓网页,十有八九抓不全,还经常失败。这种又脏又不稳的活,我会交给成熟工具。比如 Readwise Reader、Obsidian 网页剪藏,甚至你手动复制都行。

我平时刷到值得看的内容,先随手存进稍后读。正文这件脏活,稍后读工具已经替我干干净净存好了。抓取工位要做的,不是去抓网页,而是从这些已保存内容里,把标题、网址、正文状态和初步分类读进来。

这本身就是一层分工:抓取这种活交给最稳的工具,AI 只干它擅长的提炼和判断。

在这七个样本里,有六个存到了正文,有一个 YouTube 演讲只有标题、没有正文。注意抓取工位的处理:它没有硬编一个分类,而是老老实实标了“没有正文”。

这是我特意要的规矩:没正文就说没有,别拿标题硬凑。

但更隐蔽的是另一种情况:有些页面正文是齐的,可标题和摘要比正文激进得多。下一道提炼工位如果偷懒,只看标题和摘要、不啃正文,照样会翻车。

于是第二步,我故意做了个反例。

我模拟一种很多人都会犯的偷懒做法:只把每页的标题和摘要喂给提炼工位,不给它正文。

大部分页还过得去。但有一页当场出事了。

那是一份数据库行业的年度报告,标题叫“采用率再创新高”。提炼工位光看标题和摘要、没读正文,就写得特别有底气:采用率爆发式增长,同比翻倍。

它还顺手把这页降了级。

抓取工位本来标的是“学习”,它看都没看正文,就改判成了“可归档”,意思是这页没什么新东西,可以收走。

这两处你先记一下:一个“同比翻倍”,一个“可归档”。

读起来特别顺、特别可信,可它俩全是只盯着标题和摘要脑补出来的。原文里压根没有翻倍,这页也根本不是什么可以收走的旧闻。

如果到这里我图省事,让这套分工一键跑到底,会发生什么?

这页是这批里唯一一份带真实行业数据的报告,却会被当成没用的旧闻收走,再也不翻。与此同时,我脑子里还会留下一个根本不存在的“翻倍”印象,以后写东西、做判断、讲课时,都可能拿它当数据。

一份真东西被丢掉,一个假数字被我当真,而且我根本不会发现。

救我的,是后面两道工位。

真正救命的是确认边界

第三个工位,核查。

我把提炼出来的笔记,连同每个网页的原文,一起交给核查工位。它要做的,就是刚才定义好的那件事:每一条要点、每个数字、每个结论,都拿回原文一条条对。

结果很直接。

那条“采用率同比翻倍、爆发式增长”,被它标成了“可疑”。理由也很具体:原文里根本没有“翻倍”这个说法,原文写的是稳步增长,大概 8%。

提炼工位刚才那句,是顺着标题和摘要写出来的。

这种会直接决定我删不删一页资料的判断,我还会换一双眼睛再验一遍。我把同一个核查工位换到 Claude 里又跑了一遍。

注意,我不是在两个工具里各写一遍核查员。它们共用同一份设定,我改一个地方,两边一起变。所以换工具再验,用的是同一套定义,不用重配。

两遍都独立把“翻倍”标成了可疑:原文是稳步增长,不是翻倍,也不是爆发式增长。

这就是让两个不同 AI 各验一遍的价值:它们各看各的,连分歧都摆给我,最后我来定。

但今天真正的关键,不在抓出一个假数字。

真正的关键,是第四个工位:确认。

我没让确认工位再核一遍,核查已经做完了。我让它干另一件事:把前面三道工位的结果,汇总成一张待办清单。

每一条它都给我一个建议:删、归档、保留,还是深读。但所有建议都停在“待确认”那一栏。

它确实把那页报告从“可归档”翻回了“该深读”,也把那条假“翻倍”单独拎出来要我核对。可它没有替我动任何东西。

要不要落地,我一条条点确认。

这就是我今天最想让你记住的一点。

AI 整理东西的时候,会一脸自信地误判。它会把你需要的资料标成可以收走,也会编一个原文里根本没有的结论。你要是信了它、让它一键执行,你的知识库就被悄悄改坏了,你还不知道改在哪。

所以最后这一步,必须人来拍板。

这一层,就是你那套 Agent OS 真正的确认闸。前面那些工位再能干,也只是把活干完、把建议摆好;按不按那个确认键,从头到尾是你。

Agent OS 最重要的不是自动化,而是可控的自动化。

行业也在往这个方向走

这不是我一个人的偏好。

现在不同公司用的词不一样。OpenAI 讲 Agents SDK,Anthropic 讲 effective agents,Microsoft 讲 Agent Framework,Google 讲 ADK,AWS 讲 AgentCore。名字不同,但如果把这些东西拆开看,你会发现它们都在补同一组底层能力:让 Agent 有清楚的角色、上下文、状态、工具权限、审批机制和可观测性。

更简单地说,只给模型一个 prompt 已经不够了。你得给它运行结构。

什么时候该拆 specialist?不是因为多 Agent 看起来高级,而是因为不同角色需要不同的指令、上下文、工具权限和验收标准。

什么时候必须人工确认?不是因为我们不信 AI,而是因为删除、归档、发布、发邮件、改长期记忆这些动作,一旦落地就会改变真实世界或长期资产。它们不能只靠一个看起来很顺的回答自动执行。

所以我不太相信那种“给 Agent 接上一堆工具,它就能接管你工作”的说法。

接管不是能力,是风险。

你真正需要的是一套清楚的工作结构:目标入口、工位分工、上下文隔离、权限边界、执行记录、人工确认、记忆沉淀。

这不是被抛弃的旧思路。恰恰相反,这是 Agent 走向真实使用时绕不开的方向。

个人怎么开始搭一套 Agent OS

如果你现在想搭自己的 Agent OS,不要一上来就做一个大系统。

先找一个重复发生的真实任务。

比如整理标签、写 Newsletter、消化 Reader、做视频脚本、处理会议记录、整理竞品资料。选一个你每周都会遇到、每次都觉得麻烦、但结果又很重要的任务。

然后按六步走。

第一步,写清楚目标。 不要写“帮我整理资料”。写成“把这 20 篇已保存网页整理成待确认提案,最后由我决定哪些深读、哪些归档、哪些删除”。

第二步,画出工位。 别先问用哪个工具。先问这件事天然分成几段。输入、提炼、核查、确认,通常是最基础的四段。

第三步,给每个工位写清四件事。 角色、任务、上下文、验收标准。只要这四件事写不清楚,你就还没有真正定义这个工位。

第四步,补上禁止动作。 抓取工位不能脑补正文。提炼工位不能把标题当正文。核查工位不能替笔记圆场。确认工位不能自动删除。

很多人只写“你要做什么”,很少写“你不能做什么”。但在 Agent 工作流里,不能做什么经常更重要。

第五步,定义交接产物。 抓取工位输出抓取清单。提炼工位输出提炼笔记。核查工位输出核查表。确认工位输出待确认提案。

一旦每一步都有文件或表格,系统就可恢复、可检查、可替换。今天用 ChatGPT,明天用 Claude,后天用 Codex,流程仍然在。

第六步,加确认边界。 所有删除、归档、发布、发邮件、改知识库、改长期记忆的动作,都停在待确认。

你可以让 AI 给建议。不要让它悄悄替你落地。

这就是从“会用 AI”到“会建系统”的分界线。

你不一定要从 Claude Code 开始

我这次视频里会展示 Codex 和 Claude Code,因为这是我自己的主力工具。但这不是门槛。

如果你什么都没装,只用 ChatGPT,也可以先开四个对话框:

  • 第一个对话框叫抓取工位

  • 第二个对话框叫提炼工位

  • 第三个对话框叫核查工位

  • 第四个对话框叫确认工位

每个对话框只做自己的事。不要混用。不要让它自己查自己。不要让它自动执行高风险动作。

等你跑通了,再把这些 prompt 沉淀成 Claude / Codex 的 agent 或 skill。再往后,才需要考虑一套真正的 control plane。

这条路看起来慢,实际更快。

因为你不是在堆工具。你是在训练自己的系统设计能力。

模型是租来的,上下文是自己的

四个工位跑完,你注意到没有,从头到尾拿主意的一直是你。

哪页留,哪页收走,那条假笔记信不信,都是你说了算。AI 分了工、干了活,按确认键的人没换过。

我今天用了 Claude Code,也用了 Codex。但说到底,它们都是工具,是租来的。下个月出个更强的,我随时会换。

可有一样东西换不走,是我自己的。

模型是租来的,上下文是我自己的。

而这个上下文,不只是你存了多少资料。它还包括你怎么分工、怎么喂料、怎么验收、怎么决定什么可以落地。

工具一直在变,这套东西不变。

所以别再纠结哪个 AI 最强了,也别以为会建一个 Agent 就到头了。最强的从来不是某个模型,也不是某一个 Agent,是你自己这套安排。

你不一定要会建 Agent,那不是门槛。先开四个对话框,把这四个角色分清楚,让它们互相盯着,最后自己按下那个确认键。

从今天手上这一堆标签开始,你就是自己那套 Agent OS 的 operator。

工位包我也准备好了

这期视频的配套工具包,我放在这里:

→ 领取《AI 工位提示词包:标签消化版》

备用复制链接:https://img.axtonliu.com/downloads/2026/06/Claude-AI-Workstation-Prompt-Pack-Tag-Digestion-v1.0-ascii.zip

里面不是神奇自动化脚本,而是一套可以直接复制的工位定义:

  • 抓取工位 prompt

  • 提炼工位 prompt

  • 核查工位 prompt

  • 确认工位 prompt

  • 分工决策表

  • 确认边界清单

  • 给进阶用户的 Claude / Codex 跨工具共用 setup

轻度用户只要开四个 ChatGPT 对话框就能跑。进阶用户可以把它做成自己的 agent 和 skill。

你不需要先拥有一个完整的 Agent OS,才开始用 Agent OS 的方式工作。

你可以先从一个工位开始。

把一件重复发生的事拆开。给每一步写清楚上下文和验收标准。让 AI 干活,让另一个 AI 查它,让最后一步停在你面前。

挑一件手上正头疼的事,今天就排一次分工试试。

参考来源

  • Anthropic: Building Effective Agents

  • Anthropic: Effective Context Engineering for AI Agents

  • OpenAI Agents SDK: Orchestration

  • OpenAI Agents SDK: Guardrails and Approvals

  • LangChain: Multi-agent systems

  • Microsoft Agent Framework Overview

  • Google Agent Development Kit

  • Model Context Protocol Specification

  • OWASP AI Agent Security Cheat Sheet

相似文章

本文系统梳理了AI Agent架构与工程实践,涵盖控制流、上下文工程、工具设计、记忆、多Agent组织、评测、追踪和安全,基于OpenClaw实现展开,强调Harness(测试验证基础设施)对系统稳定性的关键作用。

X AI KOLs

本文系统梳理了AI Agent架构与工程实践,涵盖控制流、上下文工程、工具设计、记忆、多Agent组织、评测、追踪和安全,基于OpenClaw实现展开,强调Harness(测试验证基础设施)对系统稳定性的关键作用。

@knoYee_: https://x.com/knoYee_/status/2062780637677752366

X AI KOLs Timeline

作者复盘了使用多Agent协作三个月的经验,总结出五个主要痛点(如Agent间矛盾、忽略边界条件、自我审查失效、合并决策困难、压缩执行后暴露更难问题)和两个心得(只读审查Agent价值高、Agent矛盾暴露需求模糊),强调了人类在AI协作中的核心决策作用。

@aiDotEngineer:真正能投入生产的多智能体架构 https://youtube.com/watch?v=ow1we5PzK-o… 实际可用的多智能体编……

X AI KOLs Timeline

本文深入解析了FactoryAI的Missions多智能体架构,通过角色分工、验证合约与结构化交接机制,实现了可在生产环境中连续稳定运行数十天的自动化编码系统。该设计将软件工程瓶颈从人工执行转向人类注意力管理,为开发者提供了可落地的长期多智能体协作方案。