Twitter AI Agent - 2026-08-18¶
1. 人们在讨论什么¶
1.1 上下文不再只是“聊天记录”，而成了需要管理的资产（🡕）¶
至少有四条被保留的内容把上下文视为真正的产品层。讨论重点不再是如何通过一个提示词得到更聪明的回答，而是企业记忆存在哪里、如何跨模型延续，以及将其集中管理会带来多大风险。相比 8 月 17 日对持久化计算机和代码仓库托管的关注，8 月 18 日更深入地讨论了共享上下文本身的机制。
@rauchg 认为 (1,070 个赞，52 条回复，79,797 次浏览，498 个收藏) 认为，“软件工厂”应该采用 monorepo，让设计、营销、销售、工程和支持团队的上下文都集中在一个地方，供智能体在其上构建。这个观点并不只是为了方便人类组织代码，更是为了让智能体系统能够读懂企业完整的运营上下文。最尖锐的回复立即给出了制衡观点：当一个困惑或被错误提示的智能体能够看到一切时，收益越大，潜在爆炸半径也越大。
@MichaelLevin 报道称 (42 个赞，6 条回复，17,377 次浏览，33 个收藏) 表示，Buzz 通过让多个智能体和多个订阅共享同一段对话，解决了自己最大的摩擦点之一，因此即使中途把同一个智能体从 Claude 切换到 GPT，任务也能继续推进。但他更重要的一点是否定性的：长时间运行的工作仍然需要人工盯守。由于被中断的任务无法可靠地自行恢复，他最近大约发了十几次状态催促。这让讨论从“共享聊天”转向了持久化任务状态、检查点和可见的智能体状态。
@tom_doerr 分享了 (16 个赞，1 条回复，3,396 次浏览，22 个收藏) 将 Potpie 描述为代码库的“活态上下文图谱”。其公开仓库和网站让这一主张变得具体：它会索引代码、源码历史、决策、团队知识和工作流，让智能体能够基于项目特定上下文解决任务，而不是只面对一个裸代码检出目录。这一点很重要，因为它把上下文重新定义成可查询的图谱产品，而不只是更长的提示词或更大的记忆文件。
@milesdeutscher 分享了 (81 个赞，23 条回复，15,276 次浏览，98 个收藏) 发布了一条迁移提示词，要求 Claude Code 或 Codex 将技能、记忆文件、重复性工作流和业务上下文打包成适配不同角色的 Markdown，供 Grok Bot 集群使用。最有价值的回复并没有质疑迁移上下文的需求，而是追问：当多个智能体共享同一份角色文档时，这些角色能否保持一致；当计费模式发生变化时，经济性是否也会随之改变。
讨论要点： 回复不断区分“拥有更多上下文”和“知道谁能在何时使用这些上下文，以及使用后的影响范围”。共享对话、monorepo 和角色包看起来都很有用，但信任与同步问题比便利性叙事更明确地暴露出来。
与前一天的对比： 8 月 17 日认为，控制点正从聊天界面下沉到自有计算机和托管代码仓库。8 月 18 日则将这一论点延伸到共享记忆、上下文图谱，以及能够跨越单次会话或单一服务商持续存在的可复用角色包和上下文包。
1.2 新的智能体产品越来越多是在既有运行时之上封装，而不是取而代之（🡕）¶
当天最明确的发布并不是巨型的一体化重构，而是封装层、sidecar 和精简运行时：一个微型可嵌入 harness、一个基于 Goose 的桌面界面、一个构建在 Claude Code 之上的 24/7 助手，以及一个旨在教会现有编程智能体如何构建和部署智能体的 Google 生命周期工具。整体构建方式更偏向组合式，而不是单体式。
@vercel_dev 推出了 (347 个赞，21 条回复，37,679 次浏览，202 个收藏) 将 fx 描述为一个用 Zig 编写的微型原生开源编程智能体 harness。公开仓库补充了推文发布信息中缺失的重要细节：skills、MCP、ACP、实验性的 WebAssembly 嵌入，以及一个在终端中更像 Unix shell 而非 IDE 的 CLI。回复明确指出了其架构含义：当运行时足够轻量，可以用于沙箱和生成子智能体时，模型选择就会从产品锁定变成运行时拨盘。
@TFTC21 报道称 (60 个赞，7 条回复，19,113 次浏览，43 个收藏) 表示，Block 开源了 Berd，这是其团队用于跨项目、技能、工具和模型与智能体协作的桌面应用。公开文档显示，Berd 通过 ACP 与 Goose 通信，由 Goose 负责智能体循环，而桌面应用负责项目、会话、服务商和上下文。这是对运行时和工作界面的清晰分离，而不是又一个隐藏的单体系统。
@DanKornas 分享了 (5 个赞，2 条回复，871 次浏览，9 个收藏) 介绍了 Friday：一个基于 Claude Code CLI、Telegram、Flask 记忆服务器、SQLite、定时任务和 MCP 插件构建的 24/7 助手。这个仓库值得关注，是因为它明确拒绝增加额外的框架层：Claude Code 就是运行时，构建者只是在其周围增加记忆、通信渠道和 cron，而不是另造一套编排引擎。
@akshay_pachaar 梳理了 (27 个赞，2 条回复，4,007 次浏览，38 个收藏) 将 Google 的 Agents CLI 与 Agent Runtime 组合成一条从设置、构建、部署、治理、评估到发布的自然语言路径。Google 的公开文档基本与帖子一致，并补充了企业级组件——Terraform、Cloud Build、IAM、VPC-SC 和托管运行时——进一步印证了同一种模式：通过一层轻量的生命周期工具，让现有编程智能体更擅长处理智能体相关工作。
讨论要点： 最有力的回复集中在职责分离上。人们关注的不只是工具变多了，而是哪个层负责循环、哪个层负责界面、哪个层负责部署，以及这套技术栈有多少部分能够保持模型无关。
与前一天的对比： 8 月 17 日关于 harness 的讨论聚焦于开源模型的经济性和平台所有权。8 月 18 日则将其进一步落实为具体的发布模式：更轻量的运行时、明确的 sidecar，以及围绕现有智能体核心构建的公开封装层。
1.3 瓶颈从智能体能力转向验证、治理和成本控制（🡕）¶
几条最有影响力的帖子都认为，模型质量已经不再是全部。更难的问题是：当智能体离开演示环境后，如何批准、监控、恢复运行，以及如何为其付费。因此，这一天的讨论比前一天更加偏向运营。
@businessbarista 认为 (20 个赞，10 条回复，3,612 次浏览，42 个收藏) 认为，企业级 vibecoding 在公司选择全面放开或全面禁止时都会失败。他提出的六步“Citizen SDLC”用发现、申请、分流、配置、构建以及运行/变更阶段，取代了这种虚假的二选一，既让非工程人员保持生产力，也避免 IT 团队承担无限的安全与审查风险。回复虽然简单，却很能说明问题：获得批准的规范化路径和明确的责任人，比假装影子 AI 不会出现更重要。
@michaelzixizhou 宣布 (39 个赞，15 条回复，73,648 次浏览) 将 Codag 描述为智能体工具的压缩与控制层，YC 页面则进一步阐明了这一点：在模型读取工具结果前先进行压缩，报告工具和 MCP 的使用情况，并直接在工具路径层面衡量支出与节省。最有用的回复把这一主张转化成日常痛点：在真正开始推理前，智能体往往已经把大部分窗口浪费在原始 stdout 和日志上。
@mardehaym 认为 (22 个赞，9 条回复，1,070 次浏览，12 个收藏) 表示，“采用很容易，转型却不容易”。他附上的幻灯片进一步明确了三个反复出现的停滞点：上下文分散、流程没有改变，以及产出无法被快速验证。他的核心比较直截了当却很有说服力：工程领域最先完成转型，是因为测试能在几秒内给出通过或失败的结果；大多数其他职能仍然缺少这样的反馈闭环。
讨论要点： 在企业相关帖子中，大家共同需要的并不是更多“AI 席位”，而是门禁、检查点、可搜索的产物，以及有边界的方法来判断一次智能体运行是在正常工作、等待、受阻，还是成本过高。
与前一天的对比： 8 月 17 日的治理讨论聚焦于技能扫描器、VPC 隔离和部署边界。8 月 18 日则将控制问题扩展到申请流程、验证闭环，以及完整智能体工作流中的单工具成本可见性。
2. 人们感到沮丧的地方¶
持久化委派仍然需要人工盯守、可见性和有边界的恢复机制¶
反复出现的挫败感并不是智能体无法完成有用的工作，而是人们仍不相信它们在自己离开后能够正确地持续工作。@MichaelLevin 报道称 (42 个赞，6 条回复，17,377 次浏览，33 个收藏) 表示，Buzz 比他之前的工作流更好地解决了共享上下文问题，但仍然需要发出大约十几次状态催促，因为被中断的工作无法可靠地恢复。@milesdeutscher 分享了 (81 个赞，23 条回复，15,276 次浏览，98 个收藏) 发布了一条 Grok Bot 迁移提示词，而回复立即追问上下文漂移，以及多个智能体同时读取同一份角色文档时会发生什么。@viticci 报道称 (62 个赞，9 条回复，5,108 次浏览，30 个收藏) 认为，iOS 上的 Grok Bot 感觉新颖且完成度不错，但隐藏工具调用、没有模型选择器，让整个过程更难取得信任；回复进一步指出，不同的 bot 指令仍然建立在同一个持久化文件系统之上。如今，人们只能通过留在共享对话中、手动检查进度，以及保留人工审批环节来应对。严重程度：高。值得投入构建：高。
当上下文、责任归属和验证仍然模糊时，企业推广就会受阻¶
第二个挫败点在于，“安装 AI”并不等于改变工作方式。@businessbarista 认为 (20 个赞，10 条回复，3,612 次浏览，42 个收藏) 认为，全面批准会制造安全债务，而全面禁止只会把人们推向影子 AI，因此任何认真的推广都需要明确的申请、分流、配置和责任归属路径。@mardehaym 认为 (22 个赞，9 条回复，1,070 次浏览，12 个收藏) 认为，大多数推广之所以停滞，是因为上下文仍分散在各种工具中，流程没有改变，而且没有人能足够快地验证 AI 产出，从而取消人工审查。即使是 @akshay_pachaar 梳理了 (27 个赞，2 条回复，4,007 次浏览，38 个收藏) 发布的、较为乐观的基础设施帖子，也把同样的要求转化成了云生命周期术语：治理、评估、发布和观测都是一等阶段，而不是事后补救步骤。如今的应对策略，是在允许更大范围的自主性之前，先把明确的责任人、审批检查点和类似测试的验证机制强行嵌入工作流。严重程度：高。值得投入构建：高。
原始工具输出和分散的项目记忆在推理开始前就浪费了 token¶
第三个挫败点更隐蔽，却高度具体：智能体在无用上下文上消耗预算。@michaelzixizhou 宣布 (39 个赞，15 条回复，73,648 次浏览) 将 Codag 视为压缩与控制层，因为搜索、测试、构建、日志和 API 响应经常以重复的原始输出形式送达模型；一条回复描述了这样的会话：在真正开始推理前，大约 80% 的上下文窗口就被 stdout 和 stderr 吃掉了。@tom_doerr 分享了 (16 个赞，1 条回复，3,396 次浏览，22 个收藏) 认为 Potpie 有价值，正是因为单纯的代码检出目录并不够：智能体需要决策、历史和工作流上下文，而不只是文件。@rauchg 认为 (1,070 个赞，52 条回复，79,797 次浏览，498 个收藏) 下对 monorepo 的最佳反驳，也从另一个角度表达了同一个观点：集中上下文很容易，难的是保持其最新状态并正确限定范围。目前的解决办法，是在模型看到上下文之前先进行压缩、索引或图谱化。严重程度：中到高。值得投入构建：高。
3. 人们希望存在什么¶
统一的智能体工作区：上下文可移植，同时边界清晰可见¶
最明确的日常愿望并不是再增加一个模型，而是提供一个能够运行多个模型、又不失去控制的地方。@MichaelLevin 报道称 (42 个赞，6 条回复，17,377 次浏览，33 个收藏) 认为，跨模型共享对话上下文已经很有用，但持久化任务状态、检查点和可见状态仍然缺失。@viticci 报道称 (62 个赞，9 条回复，5,108 次浏览，30 个收藏) 认为，即使 Grok Bot 的移动端体验很新颖，也需要工具调用开关和模型选择器。一份互动不多、却异常具体的原型来自 @piotr_jura 展示了 (3 个赞，22 次浏览)，它准确展示了高级用户似乎想要的东西：一款同时覆盖 macOS 和 iPhone 的原生应用，支持多个 harness 和 worktree，提供可检查的评审，并允许明确选择模型。现有产品已经部分满足这些需求，但控制边界问题仍未解决。机会：有竞争力。
面向公民开发者的企业安全规范化路径¶
人们并不是抽象地要求减少自主性，而是希望拥有更安全的铺设道路。@businessbarista 认为 (20 个赞，10 条回复，3,612 次浏览，42 个收藏) 认为，企业需要的是一套面向非工程人员、从申请到运行的完整流程，而不是简单的“是/否”政策。@mardehaym 认为 (22 个赞，9 条回复，1,070 次浏览，12 个收藏) 认为，缺失的关键不是席位数量，而是可验证性。@akshay_pachaar 梳理了 (27 个赞，2 条回复，4,007 次浏览，38 个收藏) 则展示了同一需求的云原生版本，将治理、评估、发布和观测设为明确阶段。这是一项具有现实需求的工作，会立即影响预算、合规和责任归属。机会：直接。
围绕工具输出和产物的上下文控制基础设施¶
第三项需求，是能够决定模型究竟应该读取什么的基础设施。@michaelzixizhou 宣布 (39 个赞，15 条回复，73,648 次浏览) 将 Codag 视为一种在模型付费处理工具结果之前对其进行压缩的方式，同时还能展示各种工具和 MCP 服务器的使用情况与支出。@tom_doerr 分享了 (16 个赞，1 条回复，3,396 次浏览，22 个收藏) 将 Potpie 视为活态上下文图谱，正是因为原始文件无法保留决策、历史和工作流结构。人们似乎想要的不只是“更多记忆”，还需要一层控制机制，用于筛选、排序、压缩并解释哪些内容最终进入了上下文。机会：直接。
记住正确的内容，而不只是记住更多内容的记忆系统¶
最强烈的记忆需求，是一种能够跨会话持续改进、却不会变成盲目累积的持久化系统。@milesdeutscher 分享了 (81 个赞，23 条回复，15,276 次浏览，98 个收藏) 发布了一条迁移提示词，用于将技能、偏好和重复性工作流转化为可移植的角色文档。@DanKornas 分享了 (5 个赞，2 条回复，871 次浏览，9 个收藏) 介绍了 Friday：一个基于 Claude Code 的助手，配有 Flask + SQLite 记忆服务器、定期反思机制，以及通过 MCP 连接的外部工具。实际需求并不是无限回忆，而是能够跨会话保留、保持可解释，并为下一项任务提供支持的选择性记忆，让用户不必每次从头重建上下文。机会：直接。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| bot / Grok Bot | 多智能体云工作区 | (+/-) | 基于智能体的组织方式、群聊、持久化 Linux VM、出色的移动端体验、云端智能体交接 | 工具调用隐藏、没有模型选择器、共享文件系统的信任问题、上下文边界不明确 |
| Buzz | 共享上下文的多模型工作区 | (+/-) | 将多个订阅放在同一房间，在模型切换时保留上下文，支持智能体之间的对抗式评审 | 长时间委派仍需人工盯守；状态、恢复和故障转移目前还不够持久可靠 |
| Berd | 桌面智能体工作区 | (+) | 持久化项目、上下文清晰可见、多模型/多 harness 工作流、易用设计、通过 ACP 连接 Goose | 仍处于早期阶段的开源应用；依赖服务商配置和 Goose sidecar/运行时 |
| fx | 轻量级 harness / CLI | (+) | 原生 Zig 二进制文件、低开销运行时、与服务商无关、可嵌入的 ACP/WASM 接口、类似 shell 的体验 | 处于实验阶段且有意保持精简；工作流覆盖面窄于更重型的智能体环境 |
| Potpie | 上下文图谱 / SDLC 层 | (+) | 索引代码、历史、决策和工作流；为智能体提供项目特定上下文；CLI 优先且了解 harness | 增加设置、守护进程和图谱维护成本；团队必须持续维护这一额外层 |
| Codag | 工具输出压缩 / 控制层 | (+) | 在模型摄取前缩减工具结果，衡量工具和 MCP 的使用情况，展示跨服务商的支出/节省 | 处于发布初期；只能控制一个失效层面，无法单独解决规划或验证问题 |
| Agents CLI + Agent Runtime | 受治理的部署生命周期 | (+/-) | 脚手架、评估、部署、发布、可观测性、托管运行时、支持 IAM 和 VPC 的安全机制 | 强烈采用 Google Cloud 的模式；会带来可观的基础设施和流程成本 |
| Entire | Git 原生会话检查点 | (+) | 将提示词、转录内容和所触及文件的元数据与提交一起存储，提供可恢复检查点，保持主分支干净 | 要求团队围绕智能体会话采用 hooks 和元数据规范 |
总体而言，当工具让边界清晰可见或让上下文能够复用时，满意度会上升；当工具隐藏操作轨迹，或默认用户必须自行摸索某种云端/流程模式时，满意度就会下降。最清晰的替代方案是组合：Berd 封装 Goose，Agents CLI 教会现有编程智能体，Entire 附着在 Git 之上，Friday 则为 Claude Code 增加记忆和 cron，而不是替换运行时。迁移压力正从分散的聊天转向持久化工作区，也从原始工具输出转向压缩、检查点和上下文图谱。在企业侧，Citizen SDLC 和快速验证闭环表明，如果缺少责任归属和审查路径，单纯选择工具并不够。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| fx | Vercel Labs，通过 @vercel_dev | 用于直接使用或嵌入的微型原生编程智能体 harness 和 CLI | 为开发者提供更轻量、与模型无关的运行时，用于沙箱、基准测试和更大的智能体系统 | Zig、AI Gateway、skills、MCP、ACP、WebAssembly | Alpha | 帖子 / 仓库 / 网站 |
| Berd | Block 团队，通过 @TFTC21 和 @morganmartn | 用于跨项目、技能、工具和模型与智能体协作的桌面工作区 | 围绕现有运行时，减少界面碎片化、服务商配置和上下文处理负担 | Tauri 2、React 19、Goose、ACP | Beta | 帖子 / 仓库 / 设计 |
| Potpie | Potpie 团队，通过 @tom_doerr | 面向代码库和 SDLC 工作流的活态上下文图谱 | 让智能体获得项目特定的历史、决策和工作流上下文，而不是只面对裸代码检出目录 | Python CLI、守护进程、图谱浏览器、GitHub 和文档集成、harness skills | Shipped | 帖子 / 仓库 / 网站 |
| Codag | Michael Palmer，通过 @michaelzixizhou | 智能体工具输出的压缩与控制层 | 减少上下文膨胀，并展示跨智能体的工具/MCP 使用情况、延迟和支出 | 工具封装器、归约管道、分析、策略层 | Shipped | 帖子 / YC / 网站 |
| Friday | missingus3r，由 @DanKornas 推介 | 围绕 Claude Code 和 Telegram 构建的 24/7 个人 AI 助手 | 在不另造自定义运行时的情况下，增加持久化记忆、定时任务和外部工具访问 | Claude Code CLI、Telegram MCP、Flask、SQLite、Notion MCP、ElevenLabs、cron | Alpha | 帖子 / 仓库 |
| Entire | Entire 团队，由 @rseroter 推介 | 面向 AI 编程会话的 Git 原生捕获与检查点 | 将提示词、转录内容和所触及的文件保存为团队可见的元数据，同时不污染主分支 | Git hooks、检查点分支、CLI、worktree 支持 | Shipped | 帖子 / 仓库 / 博客 |
fx 和 Berd 展现了两种相反却互补的策略。fx 将 harness 精简到足够小，以便嵌入任何地方；Berd 则围绕外部运行时增加更整洁的桌面界面，让用户能够在一个地方管理项目、服务商和上下文。Friday 从个人构建者角度延续了同样的组合式模式：保留 Claude Code 作为运行时，再在外围增加记忆、通信渠道和调度功能。
@morganmartn 描述 (70 个赞，6 条回复，33,807 次浏览，29 个收藏) 明确强调了这一设计重点：Berd 是一个让非工程人员也觉得易用、值得每天打开的工作区，而不只是又一个技术能力强大的封装器。
Potpie、Codag 和 Entire 都属于第二种构建模式：它们并不试图成为智能体本身，而是服务于智能体周边层的产品——上下文图谱、工具输出压缩，以及带检查点的会话历史。这强烈表明，周边基础设施正在成为独立市场，而不再只是实现细节。
@jack_9947 声称 (46 个赞，80 条回复，2,567 次浏览，51 个收藏) 发布了一项宣传色彩更浓、但仍有参考价值的内容：他的团队将 GTM 工作组织成一个拥有 92 个智能体的 marketplace，覆盖潜客挖掘、定价、RevOps 报告、合作伙伴动作、支持交接和高管报告。即使这条帖子显然是在销售访问权限，帖子本身仍然很好地证明了：团队正在把业务职能拆分成几十个狭窄的智能体，而不是依赖一个通用助手。
6. 新鲜且值得关注的内容¶
Entire 将智能体式思考变成了 Git 产物¶
@rseroter 分享了 (1 个赞，1 条回复，168 次浏览) 介绍了 Entire：它能够在独立的 entire/checkpoints/v1 分支上捕获提示词、转录内容和所触及的文件。公开仓库和博客使其值得关注，因为该工具并不试图取代 Git 或编程智能体，而是将会话产物转化为可恢复、可搜索的历史，与常规代码工作并存。
一个订阅、一个 CLI、一个模型，成了严肃构建者的一种模式¶
@DanKornas 分享了 (5 个赞，2 条回复，871 次浏览，9 个收藏) 介绍了 Friday：一个完全基于 Claude Code，并在外围增加记忆、cron 和 MCP 层的 24/7 助手。它值得关注的地方不在于规模，而在于明确拒绝再增加一个框架：当构建者可以将一个现有运行时延展成持久化个人系统时，就没有必要另造框架。
AI 互动模式将问题从模型能力重新定义为用户行为¶
@BrianRoemmele 总结了 (39 个赞，8 条回复，5,659 次浏览，25 个收藏) 提出了一套研究框架，认为长期结果与其说取决于“使用 AI”，不如说取决于人们是否会验证、质疑和设定问题，而不是被动接受输出。这一点在当天很重要，因为许多其他推文实际上都在讨论如何构建系统，迫使用户回到更高主动性的模式，而不是让自动化保持流畅却不透明。
7. 机会在哪里¶
[+++] 面向智能体工作的上下文控制基础设施 —— Potpie、Codag、Entire 以及 Buzz 提到的问题，都指向同一个缺口：团队需要一层机制来决定哪些上下文进入模型、哪些内容需要建立检查点、哪些内容保持可查询，以及工具路径的成本是多少。这一机会很强，因为它在同一天同时出现在开源仓库、商业发布和从业者痛点报告中。
[+++] 面向非工程人员软件构建的企业规范化路径 —— Citizen SDLC、“采用很容易，转型却不容易”的幻灯片，以及 Google 的生命周期技术栈，都指向一个非常实际的需求：为 AI 构建的软件提供申请受理、责任归属、环境配置、验证和受控变更管理。这一机会很强，因为它已经有预算、风险负责人，以及来自多条帖子的重复表述。
[++] 具有明确状态边界、可检查的多智能体工作区 —— Grok Bot、Buzz、Berd 和 piotr_jura 的原型都显示出一种需求：在不隐藏工具调用、共享文件系统或恢复状态的情况下，在一个地方管理多个智能体、模型和项目。这一机会属中等，因为相关产品正在快速出现，但信任和边界问题仍然明显没有解决。
[+] 更具主动性的个人助手系统 —— Friday 和 Brian Roemmele 的研究框架表明，市场需要能够保持连续性，同时让用户继续承担验证、质疑和设定问题角色的助手，而不是让用户停留在被动提示后直接交付的习惯中。这个信号比企业和控制主题更早期，但既有实际构建模式，也有清晰的理论解释来支持其重要性。
8. 要点¶
- 上下文管理是当天最深层的控制点。 最有影响力的帖子讨论的是 monorepo、共享对话、可移植角色文档和活态上下文图谱，而不是某个模型击败另一个模型。（来源、来源、来源）
- 最有意思的新产品都在封装或强化现有运行时。 fx、Berd、Friday 和 Google 的生命周期工具，都把运行时视为可以嵌入、包裹或加以引导的一层，而不是每次从零重建。（来源、来源、来源、来源）
- 持久化自主性仍然是缺失的功能。 共享上下文正在改善，但人们仍然担心上下文漂移、隐藏的工具调用、模糊的状态共享，以及长时间工作仍需人工盯守。（来源、来源、来源）
- 企业 AI 推广如今成败取决于验证和责任归属路径。 主导性的运营语言是发现、分流、配置、治理、评估和审批，而不是席位数量或笼统的乐观情绪。（来源、来源、来源）
- 围绕工具路径本身的独立市场正在形成。 压缩、会话检查点和上下文图谱正在成为产品，因为原始输出、分散的产物和不可见的历史已经构成了重要瓶颈。（来源、来源、来源）