Agent IM与Agent OS:AI时代的流量入口 ✍ Yangyi🕐 2026-04-26📦 10.4 KB 🟢 已读 𝕏 文章列表 文章探讨了AI时代下人机交互的新形态。作者认为,随着模型能力的质变,类似于Telegram的“Agent IM”将成为Multi-Agent协作的基座,通过任务驱动的群聊隔离上下文。同时,针对信息过载问题,作者进一步提出了“Agent OS”的概念,即通过本地化部署、分层交互提示以及全能“大管家”Agent,解决上下文管理与权限控制问题,预言未来流量的入口将属于掌握用户最多上下文数据的系统。 Agent IMAgent OS多模态交互MultiAgent上下文管理本地化部署产品设计未来趋势AI协作交互分层 # Agent IM与Agent OS | AI时代的流量入口 **作者**: Yangyi **日期**: 2025-09-26T04:05:11.000Z **来源**: [https://x.com/yangyi/status/2048212793116201138](https://x.com/yangyi/status/2048212793116201138) ---  # Agent IM的思考起源 从25年4月我就一直在思考一个以task来驱动的人与Agent进行通讯的IM形态 这个形态类似Telegram > **Yangyi@yangyi**: [原文链接](https://x.com/yangyi/status/1971425795429351834) > > 如果你能看懂这张图 > 你就会意识到 一定会出现一种支持人与agents交互的IM > 但这个IM到来之前 > 底层的框架会需要先支持这个事情 > 任务驱动的群组最大的意义在于隔离上下文 > 这个框架是任何MultiAgents的开端 > 如果你说你在做MultiAgents,你围绕的所有事情都会在这个版图之内 > >  在这个Telegram中,人和人,人和Agent,Agent和Agent,都应该可以进行相互通讯 他们流通了相应的上下文,通过群聊来驱动一些任务达成目标 这个IM可以作为一种上下文信息通讯的基座,在Agent框架背后进行展开 当然,它也可能作为一种表现层附带GUI的产品形态出现 因为不论做什么,Agent只要出现了Swarm,就会出现协作,那么就非常会类比人类的协作方式,为了达成某种目标,而构建交流群 这个想法之所以出现,是因为那时候我在做一个MultiAgent产品,发现人,Agent,都需要进行上下文传输,但框架对此支持的并不够灵活 所以就在想,最终抽象出来的东西,究竟是什么呢? 那时候的答案就是一个属于人类与Agent的Telegram # Telegram有什么不同 当时为什么觉得是一个Telegram? 有几个原因: - Telegram中对Bot的支持是最开放最好的 - Telegram中有灵活的小组件和小程序,方便Agent给人类展示与使用 - Telegram开源,更方便构建出GUI+Agent框架 在开放的状态下,Agent能获得最大化的发挥,尤其是在工具和内容展示的表现上 # 近期的Agent IM 从SlockAI发布后,我发现这种共识达成的速率越来越快了 我在之前撰写的文章中有提及一些产品和思考,比如SlockAI,比如我设想的牛马AI的Agents  https://yangyixxxx.substack.com/p/ai2026 然后我发现,4月开始,大家在此达成了共识,有越来越多的产品都进入了这种形态 比如超平在做的Bloome:  Bloome最有特点的地方是基于群聊的widget控件,这就很像一个小APP,能帮助人们更便捷的使用一些工具 比如Sheet0团队做的Helio:  也是携带了分组channel,直聊,与任务看板 再比如推特上看到的各类独立开发者做的产品 > **Zayn Hao@ZaynHao**: [原文链接](https://x.com/ZaynHao/status/2048006415625945182) > > 如果你的 Claude Code 有一个新的使用场所。 > >  你会发现,大家都在做类似的东西,都在这个时刻达成了某种共识,仿佛AgentIM要爆发了,就像3月份爆发龙虾客户端一样 # 为什么是现在 为什么之前没有出现,而是现在出现的? 这个想法,其实很早之前就早都被人想到了 23年有AI的时候,就已经有人做多AI的群聊了 24年也有GPTs的群聊 但都没有场景 从能力上讲,当时受限于模型能力,infra能力,与代码能力 - 模型能力不足,大部分任务是无法驱动完成的 - 无法持续完成各类长程任务 - computer use和browser use,失败率极高 - 上下文窗口不够大 - infra能力不够 - skill未出现,mcp封装不足 - Agent Swarm框架较少,上下文处理缺少优化策略 - 代码能力较弱 - 3.7虽然出现了拐点,但那时候的基建仍然不够,Claude Code未出现,无法进行规模化生产 - 元能力不够,比如元工具(协助Agent构建工具的工具) 从信息上讲,近期的信息激发了人们在这方面的思考与探索 - 在Openclaw之后,大家才意识到Agent的能力发生了质变 - 场景的拓展带来了对复杂任务的期待,以前有复杂任务,但不认为能搞定,现在看到openclaw后,认为出现了Agent协同搞定复杂任务的机会 - 龙虾客户端带来了一些体感上的变化,激发了这种场景需要 从成本上讲,编码能力显著提升,构建成本显著下降 - 从前想做这类的产品,需要大量时间投入,关于IM在websocket长连接上的建设门槛很高 # Agent IM的分级交互 Agent IM在对话交互上,从信息密度由低到高,有三级: - TUI(Text User Interface):Agent仅使用文本进行回复,适用于短小的命令确认,或任务进度状态同步 - Component:基于IM的消息GUI样式,这种GUI消息卡片有效的优化了信息展示,将繁琐的非结构化文字信息,转化成结构化的富有信息层级的GUI样式。比如飞书卡片:  - Pages:当信息过载时,往往会进行如下压缩: - TUI解决最重要的不能错过的信息,符合金字塔原理 - Component解决次重要的结构化信息 - 深入的详细信息,折叠到Component Link到的Pages里,这里往往承载在一些SaaS 、 App、Widget中 分级交互其实和人类进行汇报是很类似的 - 有时候回复确认,只需要飞书中回一条消息 - 有时候汇报,需要简短的结构化描述,呈金字塔状 - 有时候老板希望知道详细细节,需要文档和PPT,这就是Pages了 信息不断分层降级,以便保有人的注意力 # Agent IM即将面临的问题 当大家都开始构建Agent IM产品时 人们总会意识到,IM只是其中一种解决策略,而不是终极基座 因为人类的信息输入带宽极其有限,以至于无法承载过量信息 如果你养过很多龙虾,你就会发现,信息是极度过载的 你可能会出现多个channels,多个私人聊天,一会儿就999+消息 信息如果无法分层,那么信息负载压力过大的时候,信息就会遗漏,导致人们无法再专注使用这个产品 最终你会发现,会出现一个管理器,来管理相关Agents的协同进程 也会发现,会出现一个「对接人」,它是一个大管家,用来做Router,帮你盯住各类任务,你只需要问它就好了 所以最终这个形态还是会和我之前演示的一样,是NewMax OS的形态  除了这个信息形态问题,上周和朋友聊天,意识到还有一个需要思考的问题是: 究竟是人驱动Agent,还是Agent驱动人? Agent的权限范围比人大,还是人的权限范围比Agent大? 当权力结构不一样时,产品形态有可能也会出现某些差异。 # Agent OS与未来办公 每个人都说Agent OS,但我定义的OS是: - 可以自定义Dashboard看板 - 将Agent Stateless的进程,Stateful化,以便监听执行流程 - 同步所有消息,在里程碑节点到达时,提示人类处理 - 有灵活的AI自实现APP的机制,并可以固化,自我迭代 我认为未来人类和AI的交互,将有两种状态: - 本地化办公交互 - 人类至少有两块屏幕,一块屏幕用来专注,一块屏幕用来展示OS的相关信息 - 专注的屏幕办公时,人类是在一个又一个处理Agent已经完成的任务,这些任务交由到人类节点进行Review和审查 - 专注的屏幕休息时,人类可以看视频,可以浏览网页 OS要做的,是信息分层提示: - 重要任务Push/响铃/主动弹出 提示 - 一般任务 状态展示提示 - 不重要的任务 折叠展示 只需要定期发Report告知处理进度即可 - 移动化办公交互 - Agent OS应该可以同步移动端,一起协同处理 - 移动端只对接大管家,大管家来自动操作本地化进程,分配任务 - 大管家其实就是任务指示器+分配专家 - 移动化设备将可以从本地云上提取,交互文件,方便进行管理 # Agent OS与OS本地云 当Agent OS出现后,我们会发现,Agent时代的入口,应该是「掌握你上下文数据最多的」那个地方 而这个地方,我认为极大概率是本地化的 至少我认为,我很难将这些数据提供给各家云厂商 另外我认为,可能会出现本地化模型,拥有处理60%场景能力的那个本地化模型 接下来可能每个人都会购买一个NAS存储,在本地搭建属于自己的个人服务器 这些Infra可能也会普适化,出现相关的简单易用的硬件服务 最终联动自己的智能家居,智能汽车,智能机器人,智能设备…… 将所有关于自己的上下文,通过RBAC权限系统来控制不同服务商进行读取,以便AI更了解自己 从前充当互联网入口的,是搜索。因为他聚合了大量的信息。他知道用户的意图,依靠search query。 未来充当入口的,是「拥有最多上下文」的地方。它将成为人类个体的代言人,去和各类Provider沟通。 我不知道谁能做出来这个Agent OS,但我知道它一定会出现。至少Claude已经开始了。 ---------------- 文章来自Yangyi实践手册👇🏻 https://yangyixxxx.substack.com/p/agent-imagent-os ## 相关链接 - [Yangyi](https://x.com/yangyi) - [@yangyi](https://x.com/yangyi) - [2.6K](https://x.com/yangyi/status/2048212793116201138/analytics) - [Sep 26, 2025](https://x.com/yangyi/status/1971425795429351834) - [51K](https://x.com/yangyi/status/1971425795429351834/analytics) - [https://yangyixxxx.substack.com/p/ai2026](https://yangyixxxx.substack.com/p/ai2026) - [16h](https://x.com/ZaynHao/status/2048006415625945182) - [20K](https://x.com/ZaynHao/status/2048006415625945182/analytics) - [https://yangyixxxx.substack.com/p/agent-imagent-os](https://yangyixxxx.substack.com/p/agent-imagent-os) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:29 AM · Apr 26, 2026](https://x.com/yangyi/status/2048212793116201138) - [2,681 Views](https://x.com/yangyi/status/2048212793116201138/analytics) --- *导出时间: 2026/4/26 12:39:02*
C Claude Code 正在创造新型开发者:从 AI 助手到智能编排 文章探讨了软件开发的范式转移,指出开发者不应仅将 AI 视为简单的聊天或代码生成工具,而应构建围绕智能体(Agent)的完整操作系统。通过优化上下文管理、工作流编排和长期记忆系统,开发者能将 AI 转化为高效的工程系统。这种从“写代码”到“编排智能”的转变,将是未来的核心竞争力。 技术 › Agent ✍ Suryansh Tiwari🕐 2026-05-30 Claude CodeAgenticAI编排上下文管理工作流软件工程Agent开发未来趋势技术栈智能系统
上 上下文工程规则已变:Anthropic 删减 80% 指令的实践 Anthropic 工程师 Thariq Shihipar 分享了构建 Claude Code 的发现,团队删除了 80% 的系统提示词后性能未受损。文章介绍了“4层上下文审计”框架,指导如何清理常驻指令、记忆、知识文件等冗余信息,以适应新模型的高推理能力,避免过度指令导致的性能下降。 技术 › LLM ✍ AI Guides🕐 2026-07-30 Prompt工程上下文管理ClaudeAnthropic系统提示词AI优化
纳 纳米Work实测:跨三家大模型制作宣传片 作者体验了纳米Work产品,通过两个真实任务测试其Agent能力。该产品成功调用多家大模型完成了产品宣传片剪辑及文案落地页制作。产品具有全过程透明、支持多模型切换及移动端接管等特点,展示了AI作为工作伙伴的巨大潜力。 技术 › Agent ✍ 花叔🕐 2026-07-29 纳米WorkAgent大模型工作流自动化产品设计视频剪辑AI办公
何 何为“掌控你的智能” 文章探讨了企业如何在通用 AI 基础上构建差异化优势。作者指出,未来五年公司需掌控智能的运作方式、管理与复利,而非仅依赖现成模型。掌控智能包括控制 Agent 系统(模型、调度逻辑、上下文)、掌控质量与风险,以及通过反馈循环积累智能,从而实现业务的深度集成与持续优化。 技术 › Agent ✍ Harrison Chase🕐 2026-07-26 AI企业应用智能体架构设计LangChain商业策略模型掌控上下文管理反馈循环
炸 炸裂,Anthropic 给 Opus 5 删掉了 80% 的系统提示词 Anthropic 团队将 Claude Code 的系统提示词删减了 80%,但编码评测没有损失。文章指出,许多规则是为老模型打的补丁,已过时。最佳实践转向:用锚点代替禁令,用接口设计代替举例,以及渐进披露。建议开发者清理“拐杖”型规则,保留护栏与品味,用评测集支撑删除决策。 技术 › LLM ✍ 码良🕐 2026-07-25 ClaudePrompt Engineering系统提示词AnthropicLLM最佳实践上下文管理
构 构建智能代理的三层架构:Loop、Graph与Harness 本文提出解决Agent重复读取数据和Token浪费的三层架构方案:Loop负责单元工作的收集-行动-验证闭环;Graph通过分发和并行管理复杂任务;Harness作为运行时环境提供工具和上下文隔离。文中提供了具体的代码实现思路和实战演示。 技术 › Agent ✍ Archive🕐 2026-07-25 AgentLoopGraphHarness架构设计上下文管理Token优化验证机制代码实现
如 如何设计 AI Agent:思维模型与实体化 文章提出 AI Agent 应被视为“思维与身体”的结合。单纯依赖大模型能力的 Agent 难以体现价值,唯有通过构建包含身份、资产、感知和限制的“身体”结构,将无界的智能具象化,才能解决用户痛点,避免沦为单纯的套壳聊天机器人。 技术 › Agent ✍ Will Chen🕐 2026-07-25 AI Agent产品设计思维模型大模型应用SaaS
推 推荐这期 Pi 插件合集 文章推荐了6个实用的Pi插件,包括必装的pi-agent-extensions、多代理协作的pi-agents-team、跨会话记忆增强插件、上下文工程工具以及连接Claude Code生态的桥梁插件,旨在提升Pi作为Agent Harness的扩展能力和效率。 技术 › 工具与效率 ✍ yibie🕐 2026-07-24 PiAgent插件Multi-AgentClaude Code上下文管理
走 走进制造业:上篇·生产之前,产品先学会承担 文章探讨了制造业设计的核心在于让产品“承担关系”,而非单纯追求外观。作者从产品定义、边界划分、接口设计、证据链管理及多尺度视角出发,阐述了如何通过科研 Agent 思维将模糊需求转化为可制造、可交付的现实系统,强调责任与风险评估在产品全生命周期中的重要性。 其他 › 杂谈 ✍ AI最严厉的父亲🕐 2026-07-24 制造业产品设计研发管理Agent思维工程方法
V Video Agent:基于 HeyGen 的视频生成智能体 文章介绍了 HeyGen 推出的 Video Agent 产品。这是一个无需代码、通过自然语言交互即可自动生成完整视频的智能体。用户只需描述需求,Agent 便会自动规划、编剧、选角并生成视频,支持风格定义和后期精细编辑。 技术 › Agent ✍ HeyGen🕐 2026-07-24 HeyGen视频生成AIGC智能体自动化视频编辑产品设计
T The context gold rush: Why everyone is building the same thing 文章分析了当前 AI 领域的“淘金热”——上下文管理。作者指出,从 Jevons 悖论到数据主权,多因素驱动了初创公司和大企业竞相构建公司大脑或 LLM 知识库。尽管切入角度各异(如个人知识库、代理内存、可观测性工具等),但核心目标一致:为未来的智能体劳动力提供数据上下文层。文章认为该领域潜力巨大,但也面临产品同质化。 技术 › Agent ✍ Sam Z Liu🕐 2026-07-24 上下文管理Agent公司大脑LLM数据主权竞争格局
A AI 产品经理的系统思维:从种花到构建智能系统 文章阐述了 AI 产品的有机特性,强调系统思维对 AI 产品经理的重要性。核心观点包括:系统行为源于组件交互、结构与规则比参数更具杠杆效应、新演员(Agent)出现时价值流向接口。实践层面建议通过分解产品、定义契约和设计反馈循环,将 Agent 深度融入产品,以建立竞争壁垒。 技术 › Agent ✍ Christine Zhu🕐 2026-07-23 AI产品系统思维Agent产品设计PM系统架构反馈循环SaaS