AI交互方式的7大转变：从提示工程到共享智能体

AI的使用方式正在经历一场静默却深刻的变革。从最早的提示工程师（prompt engineer），到上下文工程师（context engineer），再到框架工程师（harness engineer）和循环工程师（loop engineer），每一次角色的演进都不只是新术语替换旧术语的文字游戏，而是我们共同摸索如何驾驭这项全新技术的真实足迹。The AI Daily Brief 在最新一期节目中，梳理了近期一系列产品发布所折射出的七个交互模式转变——其中不少变化可能会长期沉淀下来，值得投入注意力去理解。

一、界面走向极致简化

第一个变化并非用户主动改变使用方式，而是产品设计决策在重塑我们与AI互动的选项。趋势非常明确：简化、整合，尽可能减少终端用户的认知负担和决策成本。

有意思的是，早期AI某种意义上违背了传统硅谷逻辑——通常认为用户不会为复杂体验买单。恰恰相反，大量早期采用者（不只是技术圈，也包括更广泛的知识工作者）主动扎进复杂性中。节目主持人提到，他今年推出的免费Claude训练营吸引了9000人报名，其中大多数人根本不是工程师，却愿意「趟过玻璃碴」去学习如何搭建自己的智能体。

但简化的需求同样真实存在。Meta的MUSE产品成为这一趋势的典型代表，即便是完全有能力处理复杂性的资深用户也在称赞它的设计克制。技术专家Tom Goodwin写道：「MUSE的美妙之处在于，它以极其易用的方式呈现——别告诉我它怎么运作，直接告诉我怎么用。」David Herman则分享了让近70岁的父亲通过短信就让AI生成合同、修改并发送给客户的经历，感叹「目前不到1%的人真正理解这些模型是什么，Meta把这一切变简单了」。

这种简化正在各处涌现。Anthropic本周宣布Claude的co-work与chat不再是独立功能，转向单一统一体验。Anthropic实验室负责人、Instagram联合创始人Mike Krieger指出，用户最常见的困惑就是「不知道该从哪个产品开始」，而这种摩擦恰恰阻碍了他们发挥模型的最大价值。

二、Mono Thread：单一长线程管理一切

第二个变化本质上也是一种简化，关乎我们如何「控制」AI，即向mono thread（单一线程）的转变。

mono thread的核心理念是：不再频繁切换上下文窗口、重复解释需求和撰写新提示，而是使用一个持续运行的长线程，让它继承过往对话的上下文来管理整个工作流。过去这受限于上下文窗口——填满之后AI就会「疲惫」，开始出错、丢失指令。今年早些时候的很多课程内容其实都在教人如何写好「交接文档」来在不同线程间转移上下文。

转折点来自Codex团队对compaction（上下文压缩）的持续投入。Codex的Nick Bauman写道，很多编码智能体的设计都建立在「长线程终将退化」的假设上，一旦放弃这个假设，产品方向就会豁然开朗。他在《My Codex Threads Are Alive》一文中描述，自己最有用的Codex线程已经连续使用三周——每小时检查Slack、Gmail和PR，把噪音转化为可执行的清晰信号。「我变得mono thread化了」。

如今这已成为官方能力。Claude账号本周宣布，projects现在从「一个对话」开始运行，你描述需要完成的任务，Claude会调度并行线程持续工作。Cursor在推出projects时也内置了同样逻辑——「与协调者智能体在单一持久线程中协作，而非为每个任务创建新对话」。Claude Code创造者Boris Cherny表示，projects不仅改变了他与Claude互动的方式，也改变了他写代码的方式：「我不再管理会话，只是随想随发，Claude会把它们拆分成线程。」

上下文窗口（context window）是指模型在单次推理时能够"看到"的最大文本长度，通常以token数量衡量。早期主流模型的上下文窗口仅有4K至32K tokens，这意味着一次稍长的对话或任务就会触及上限，模型开始遗忘对话前段的指令与背景。2024年至2025年间，各主要模型的上下文窗口迅速扩展至100K乃至百万token级别，这是mono thread模式得以成立的物质基础。Compaction（上下文压缩）则是另一层技术保障：当线程累积到一定长度时，系统会自动将历史对话蒸馏为更紧凑的摘要，而非简单截断，从而在有限窗口内保留最关键的工作记忆。两项技术的叠加，使得"一个线程跑三周"从理论上可行的设想变成了实际产品能力。

三、聊天机器人变身「智能体舰队管理者」

把mono thread和上述例子串起来看，会发现一个更深层的转变：聊天机器人正日益成为智能体舰队的管理者。

你交互的地方是一个协调者AI，但这个协调者会派生出大量子智能体（sub-agents）去完成工作的不同部分。有趣的是，曾几何时许多人认为聊天机器人界面只是一个过渡形态，终将被取代。但实际情况是——模型和框架公司悄悄改变了聊天机器人的「内核」，却没有抽走我们熟悉的界面地毯。我们依然享受着舒适的聊天体验，甚至因为mono thread而更加简化，但它背后所做的事情已与一年前截然不同。

Ethan Mollick评价道，Claude projects最有趣的地方在于它能很好地处理智能体团队——你与一个主编排智能体对话，它会派生出各类专家，本质上是创建了一个组织来解决你的问题，还会根据偏好混用昂贵和廉价的智能体。这也意味着，其余软件服务可能越来越像是主协调智能体的「上下文数据库」。有用户甚至表示，Gmail对自己而言基本已经沦为一个数据库，「智能体将成为我个人和职业生活的默认接口」。

四、语音成为默认交互方式

与此紧密相关的一个简单但深远的变化是：越来越多的交互将通过语音进行。

节目提到，今年发布的每个免费学习项目开篇都在敦促人们使用原生语音控制或配置类似Whisperflow的工具，因为语音带来的效率和扩展的上下文是巨大的。这正日益成为智能体产品的基本配置。Grokbot本周加入了原生语音集成，SpaceX团队的Danny Graziosi形容「用语音向你的参谋长快速下达任务、同时它编排整个机器人团队，感觉像魔法」。

Gaurav Bison点出关键：语音单独存在时总像噱头，直到智能体真能去执行实际任务，「语音+真实工作」才是致命组合。OpenAI发布了新的Codex广告，展示开发者一边健身一边用GPT live语音智能体编程；Google也推出了Gemini 3 Live及其扩展思考版本，强调智能与并行推理的升级让语音协作更直观。

五、从「提示」到「设定目标」与循环工程

伴随更强的智能体协调能力，我们给AI下达指令的性质也变了。核心转变是：不再提示（prompt）AI，而是为它们设定目标（set goals）。这天然赋予AI更大的自主空间，让它在循环中反复工作直到完成。

这始于Claude Code和Codex中的slash goal等原语，后来扩展为整个「循环工程」（loop engineering）理念。OpenClaude创造者Peter Steinberger的一句话为其助力：「你不该再直接提示编码智能体了，你应该设计能提示智能体的循环。」循环的本质在于——除了定义目标，还要定义可量化的成功标准，让智能体能自我衡量，从而持续运行直到达成目标。尽管这类术语容易招致早期采用者圈外的白眼，但它实际上是获取AI最大价值的关键思维转变。

循环工程（loop engineering）的核心机制在技术上通常被称为"评估-反馈循环"（eval-feedback loop）或"智能体循环"（agentic loop）：模型执行一步操作后，系统会将执行结果作为新的上下文输入，模型据此判断是否达成目标并决定下一步行动，如此往复直至终止条件触发。可量化的成功标准（success criteria）是这一机制能够自主运行的关键——若缺乏明确的验收标准，模型无法判断"完成"的含义，循环要么过早退出，要么陷入无意义的重复。这与传统软件工程中的单元测试逻辑高度相似：测试用例即成功标准，智能体通过"运行测试"来自我校验。对于非工程师用户而言，设定目标的实践意义在于，用户需要从"告诉AI做什么"转向"定义AI何时算做好了"，这是一种需要刻意培养的思维习惯。

六、多模型混用成为成本刚需

第六个变化是个人技术栈层面的「多模型化」（multimodality）——不仅在组织层面，甚至在单个用户的工作中也会混用多个模型。

资深用户一直把模型选择视为获益手段——不被订阅的单一模型所束缚，而是找到最适合特定任务的模型。但如今的不同在于：工作的复杂度、难度、深度和时长，加上最先进模型的成本以及标准套餐补贴的收缩，让这从「早期采用者的独门技巧」变成了成本与效率上的硬性要求。

这与「聊天机器人作为智能体舰队管理者」的趋势高度重叠。很多人注意到，像某些前沿模型的默认行为不仅用最先进模型作协调者，连所有子智能体也一并使用——结果一个看似标准的任务，因为派生出五到十个都跑最强模型的子智能体，瞬间吃掉大量用量额度。理解不同任务需要什么级别的模型能力，并将其规范化到自己的AI管理中，将成为越来越重要的纪律。值得警惕的是，这一趋势可能与「简化」趋势相悖——各实验室为了让平均体验更简单，往往会隐藏甚至取消细粒度的模型控制选项，而自动化系统未必总能判断正确。

七、共享智能体：多人协作AI的兴起

最后一个转变是「共享智能体」（shared agents）。2026年很可能会被回望为「智能体真正落地的一年」，但在这一年的前三分之二里，几乎所有智能体行为都还局限在个人层面——每个人各自搭建自己的团队，改变了个人的工作方式，却没有改变整个团队的协作方式。

这一局面正在改变。今年夏天Claude推出的Claude Tag取代了旧有的个人实例系统，转为基于团队的新机制——每个频道拥有自己的Claude，可以跨越上下文工作，而不绑定任何单一个人。MioXYZ本周作为「你整个团队共享的首个AI员工」上线，宣称在测试期间为团队节省了数千小时。

但「多人协作AI」究竟意味着什么，仍在激烈探索中。Ethan Mollick指出，这仍是当前使用AI最大的非技术难题之一，现有方案还相当原始，多停留在「AI作为群聊中的一个成员」。Aria Bhutani提出了更本质的问题：在多人智能体系统中，谁是「主体」（principal）？是用户，还是智能体本身？这是「智能体文明与人类文明以智能体速度运行」之间的区别。Atlan的Rishigar Bhatnagar则认为，多人协作AI将是2027年最大的设计难题之一——它对每个人的含义都不同：是共享记忆、共享上下文、组织设计，还是别的什么？他进一步指出，最难的部分或许根本不是技术，而是「让整个团队采纳一种共享的工作方式，这更像组织设计而非工程」。

"主体"（principal）问题是多智能体系统中的核心治理议题，源自经济学与法律中的"委托-代理"（principal-agent）框架。在传统软件场景中，指令链路清晰：用户发出指令，软件执行。但当智能体可以自主派生子智能体、代表多个用户行动时，权责归属变得模糊——智能体究竟在执行谁的意图？当不同用户的目标发生冲突时，以谁的利益优先？这一问题在个人使用场景下尚不突出，一旦进入团队协作场景便立刻浮现。共享上下文同样带来隐私与信息隔离的挑战：团队共享的智能体是否应该让所有成员看到彼此的对话记录？如何在"协作透明"与"个人隐私"之间划定边界？这些问题目前既没有业界共识，也缺乏成熟的产品实践，正是Atlan的Rishigar Bhatnagar所说"更像组织设计而非工程"的根本原因所在。

写在最后

这七个转变——界面简化、mono thread、聊天机器人成为舰队管理者、语音交互、目标与循环、多模型混用、共享智能体——共同勾勒出我们与AI关系的新形态。它们并非孤立的产品噱头，而是相互交织、彼此强化的深层范式迁移。对于希望高效利用时间的人来说，理解哪些变化会长期沉淀，本身就是一种重要的能力。