Twitter AI 智能体 - 2026-08-18¶
1. 人们在讨论什么¶
1.1 上下文不再只是“聊天记录”，而是被当成可管理资产 (🡕)¶
至少有 4 条保留下来的内容，都把上下文当成真正的产品表面。讨论的重点不再是如何靠一个提示词拿到更聪明的回答，而是公司的记忆应该存在哪里、它如何跨模型延续，以及把它集中起来到底会带来多大风险。相比 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，把它称作代码库的“活的上下文图谱”；而公开仓库和网站则把这个说法落到了实处：它会索引代码、源码历史、决策、团队知识和工作流，让智能体可以针对项目特定上下文来解决任务，而不是只面对一个裸 checkout。这里之所以重要，是因为它把上下文重新定义成一种可查询的图谱产品，而不只是更长的提示词或更大的记忆文件。
@milesdeutscher 分享了（81 个点赞、23 条回复、15,276 次浏览、98 次收藏）一个迁移提示词，要求 Claude Code 或 Codex 把技能、记忆文件、重复工作流和业务上下文，打包成适合 Grok Bot swarm 使用的 markdown 角色文档。最有价值的回复，并没有质疑“想迁移上下文”这件事本身，而是在问：当多个智能体共享同一份角色文档时，这些角色还能否保持一致；当计费模型切换后，经济性又会不会随之改变。
讨论要点： 回复一直在区分“拥有更多上下文”和“谁能在什么时机、以多大爆炸半径使用这些上下文”。共享对话、monorepo 和角色包看起来都很有用，但和“更方便”的故事相比，信任和同步问题被讲得更明白了。
与前日对比： 8 月 17 日的结论是，控制点正在从聊天 UI 下沉到自有计算机和托管仓库；8 月 18 日则把这条论证继续推进到了共享记忆、上下文图谱，以及能跨单次会话或单一提供商复用的角色 / 上下文包。
1.2 新的智能体产品越来越多地包裹现有运行时，而不是试图完全取代它们 (🡕)¶
当天最清晰的一批发布，并不是巨大的全能重造品，而是 wrapper、sidecar 和极简运行时：一个很小、可嵌入的运行框架，一个覆盖在 Goose 之上的桌面界面，一个构建在 Claude Code 之上的 24/7 助手，以及 Google 那套教现有编程智能体如何构建与部署智能体的生命周期工具。构建模式更偏组合式，而不是单体式。
@vercel_dev 发布了（347 个点赞、21 条回复、37,679 次浏览、202 次收藏）fx，把它定义成一个用 Zig 编写的、微型开源原生编程智能体运行框架。公开仓库补足了推文启动文案里缺失的重要细节：skills、MCP、ACP、实验性的 WebAssembly embedding，以及一个目标是更像 Unix shell 而不是终端 IDE 的 CLI。回复把背后的架构含义说得很明白：当运行时轻到足以被用于沙箱和生成式子智能体时，模型选择就更像一个运行时拨盘，而不是产品锁定。
@TFTC21 提到（60 个点赞、7 条回复、19,113 次浏览、43 次收藏），Block 开源了 Berd，这就是他们内部团队跨项目、技能、工具和模型与智能体协作所用的桌面应用。公开文档显示，Berd 通过 ACP 与 Goose 通信，把智能体循环交给 Goose，而桌面应用自己处理项目、会话、providers 和上下文。这是一种对运行时和工作界面的清晰拆分，而不是另一个隐藏式单体。
@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，把它看成一条从 setup 到 build、deploy、govern、evaluate、publish 的自然语言路径。Google 的公开文档和这条帖子基本一致，并补上了企业侧组件——Terraform、Cloud Build、IAM、VPC-SC 和托管运行时——进一步强化了同一种模式：用一层很薄的生命周期层，让现有编程智能体更擅长做智能体工作。
讨论要点： 最有力量的回复，都在讨论职责分离。人们并不只是在庆祝又多了几个工具；他们更在意，哪一层拥有循环、哪一层拥有 UI、哪一层拥有部署，以及这整套栈里有多少部分可以保持模型无关。
与前日对比： 8 月 17 日关于运行框架的讨论，集中在开放模型经济性和平台所有权；8 月 18 日则把话题继续推向更具体的发布模式：更轻的运行时、显式的 sidecar，以及围绕现有智能体核心的公开 wrapper 层。
1.3 瓶颈已经从智能体能力，转移到验证、治理和成本控制 (🡕)¶
当天几条最强的帖子都在说，模型质量已经不是全部。更难的问题，是智能体一旦离开 demo，应该如何被批准、监控、恢复，以及由谁来买单。结果就是，这一天的讨论明显比前一天更偏运营。
@businessbarista 认为（20 个点赞、10 条回复、3,612 次浏览、42 次收藏），企业 vibecoding 会在“全面放开”和“全面否决”这两个极端中双双失败。他提出的 6 步 “Citizen SDLC”，用 discovery、request、triage、provisioning、build 和 run / change 阶段，替代了这个虚假的二选一，目的就是让非工程人员也能保持生产力，同时不把无限的安全和审查风险全压到 IT 身上。回复很简单，但信息量很足：带官方护栏的通道，以及明确的责任人，比假装 shadow AI 不会发生更重要。
@michaelzixizhou 发布了（39 个点赞、15 条回复、73,648 次浏览）Codag，把它定位成智能体工具的压缩与控制层；YC 页面也把重点说明白了：在模型读取前先压缩工具结果，报告工具和 MCP 的使用情况，并在工具路径本身衡量花费与节省。最有价值的一条回复，把这个 pitch 翻译成日常痛点：智能体往往会在真正开始推理之前，就把大部分上下文窗口耗在原始 stdout 和日志上。
@mardehaym 认为（22 个点赞、9 条回复、1,070 次浏览、12 次收藏），“采用很容易，转型并不容易”；他附带的幻灯片则把这个判断进一步 sharpen 成 3 个反复出现的卡点：上下文分散、流程不变，以及没有人能快速验证输出。他最有说服力的对比也很直接：工程之所以先发生转型，是因为测试可以在几秒钟内给出通过 / 失败；而绝大多数其他职能仍然缺少这样的反馈闭环。
讨论要点： 在企业相关帖子中，大家共同要求的并不是更多“AI 席位”，而是闸门、检查点、可搜索的产物，以及能有边界地判断某次智能体运行到底是成功、等待中、被阻塞，还是太贵了。
与前日对比： 8 月 17 日的治理簇，强调的是 skill scanners、VPC 隔离和部署边界；8 月 18 日则把控制问题扩展成覆盖整个智能体工作流的请求管线、验证闭环和逐工具成本可见性。
2. 令人困扰的问题¶
持久委托仍然需要人工盯着、可见性和有边界的恢复¶
反复出现的挫败感，并不是智能体做不了有用工作，而是人们仍然不信任它们在自己离开后还能正确地继续跑下去。@MichaelLevin 提到（42 个点赞、6 条回复、17,377 次浏览、33 次收藏），Buzz 在共享上下文上比他早先的流程做得更好，但仍然让他不得不发出大约十几次状态提醒，因为被中断的工作无法稳定恢复。@milesdeutscher 分享了（81 个点赞、23 条回复、15,276 次浏览、98 次收藏）一个 Grok Bot 迁移提示词，而回复立刻追问上下文漂移，以及多个智能体都读取同一份 profile 文档时到底会怎样。@viticci 提到（62 个点赞、9 条回复、5,108 次浏览、30 次收藏），iOS 上的 Grok Bot 让人耳目一新、执行也不错，但它隐藏工具调用、又不给模型选择器，导致整个过程更难被信任；回复还把担忧进一步推进：不同 bot 的 instructions 最终仍然压在同一个持久文件系统之上。现在人们的应对方式，是留在共享对话里、手动检查进度，并始终保留人工审批闭环。严重度：高。值得为此构建：高。
企业推广会卡在上下文、责任归属和验证始终模糊的地方¶
第二个挫败点是，“安装 AI” 并不等于改变工作真正发生的方式。@businessbarista 认为（20 个点赞、10 条回复、3,612 次浏览、42 次收藏），全面批准会制造安全债，而全面拒绝只会把人逼向 shadow AI，因此任何严肃的推广都需要明确的 request、triage、provisioning 和 ownership 护栏。@mardehaym 认为（22 个点赞、9 条回复、1,070 次浏览、12 次收藏），大多数推广会卡住，是因为上下文还散落在不同工具里、流程根本没变，而且没有人能足够快地验证 AI 输出，从而去掉人工审阅。即便是相对乐观的基础设施贴——@akshay_pachaar 梳理的（27 个点赞、2 条回复、4,007 次浏览、38 次收藏）那条——也只是把同一要求翻译成云生命周期语言：govern、evaluate、publish 和 observe 是一级阶段，不是扫尾步骤。现在的应对策略，是在允许更广泛自治之前，先把明确责任人、审批检查点和类似测试的验证强行嵌进工作流。严重度：高。值得为此构建：高。
原始工具输出和分散的项目记忆，在推理开始前就把 token 浪费掉了¶
第三个挫败点更安静，但也更具体：智能体会把预算烧在垃圾上下文上。@michaelzixizhou 发布了（39 个点赞、15 条回复、73,648 次浏览）Codag，正是因为搜索结果、测试、构建、日志和 API 响应，往往以重复的原始输出形式直接送进模型；有条回复描述了一种会话：大约 80% 的窗口，在真正开始推理前就消耗在 stdout 和 stderr 上。@tom_doerr 分享 Potpie（16 个点赞、1 条回复、3,396 次浏览、22 次收藏），也是因为一个裸代码 checkout 根本不够：智能体需要的是决策、历史和工作流上下文，而不只是文件。针对 @rauchg 主张（1,070 个点赞、52 条回复、79,797 次浏览、498 次收藏）monorepo 的帖子，最有力的反驳其实是在换个角度说同一件事：把上下文集中起来很容易，难的是让它始终保持最新，并且作用域正确。现在的权宜方案，就是在模型看到之前，先把上下文压缩、索引或做成图谱。严重度：中高。值得为此构建：高。
3. 人们期望的功能¶
一个既能让上下文可移植、又能让边界可见的统一智能体工作区¶
最明确的日常诉求，并不是再来一个模型，而是有一个地方能同时运行很多模型，却不失去控制。@MichaelLevin 提到（42 个点赞、6 条回复、17,377 次浏览、33 次收藏），跨模型共享对话上下文已经很有用，但持久任务状态、检查点和可见状态仍然缺失。@viticci 提到（62 个点赞、9 条回复、5,108 次浏览、30 次收藏），Grok Bot 需要工具调用开关和模型选择器，即便它的移动端 UX 确实很新鲜。还有一个互动量不高、但异常具体的原型，来自 @piotr_jura 展示的（3 个点赞、22 次浏览）：一个跨 macOS 和 iPhone 的原生应用，支持多个运行框架和 worktree、可检查的审阅，以及显式模型选择。这几样拼在一起，几乎就是重度用户想要的东西。现有产品只解决了其中一部分，但控制边界问题仍然没有被真正解决。机会：竞争型。
面向 citizen builders 的企业级安全护栏¶
人们并不是在抽象地要求更少自治；他们要的是更安全的铺装道路。@businessbarista 认为（20 个点赞、10 条回复、3,612 次浏览、42 次收藏），企业需要的是一条面向非工程人员、从 request 到 run 的完整管线，而不是一个简单的 yes / no 政策。@mardehaym 认为（22 个点赞、9 条回复、1,070 次浏览、12 次收藏），真正缺的不是席位数，而是可验证性。@akshay_pachaar 则用（27 个点赞、2 条回复、4,007 次浏览、38 次收藏）govern、evaluate、publish 和 observe 这些显式阶段，把同一个需求翻译成云原生版本。这是一个会立刻影响预算、合规和责任归属的现实需求。机会：直接。
围绕工具输出和产物的上下文控制基础设施¶
第三类需求，是基础设施需要替用户决定，模型究竟应该读什么。@michaelzixizhou 发布了（39 个点赞、15 条回复、73,648 次浏览）Codag，用来在模型付费处理之前先压缩工具结果，同时把工具和 MCP server 维度上的使用与花费暴露出来。@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 | 多智能体云工作区 | (+/-) | 基于 bot 的组织方式、群聊、持久 Linux VM、很强的移动端 UX，以及云端智能体接力 | 工具调用被隐藏、没有模型选择器、共享文件系统的信任问题，以及上下文边界不清晰 |
| Buzz | 共享上下文的多模型工作区 | (+/-) | 把多个订阅放进同一个房间、在模型切换时保留上下文，并支持智能体之间的对抗式审阅 | 长时委托仍需要人工盯着；状态、恢复和故障转移还不够持久可靠 |
| Berd | 桌面智能体工作区 | (+) | 持久项目、上下文可见性、多模型 / 运行框架工作流、设计友好，且通过 ACP 接到 Goose | 仍是早期开源应用；依赖 provider 配置以及 Goose sidecar / runtime |
| fx | 轻量运行框架 / CLI | (+) | 原生 Zig 二进制、低开销运行时、provider 无关、可嵌入的 ACP / WASM 表面，以及更像 shell 的 UX | 仍属实验性，而且刻意保持极简；相比更重的智能体环境，工作流表面更窄 |
| Potpie | 上下文图谱 / SDLC 层 | (+) | 索引代码、历史、决策和工作流；为智能体提供项目特定上下文；CLI-first 且理解运行框架 | 会带来 setup、daemon 和图谱维护开销；团队还得额外维护这一层 |
| Codag | 工具输出压缩 / 控制层 | (+) | 在模型摄取前压缩工具结果，衡量工具和 MCP 使用情况，并暴露跨 provider 的花费 / 节省 | 仍是发布初期产品；它只控制其中一层失效面，本身不解决规划或验证 |
| Agents CLI + Agent Runtime | 带治理能力的部署生命周期 | (+/-) | 把 scaffolding、eval、deploy、publish、observability、托管运行时，以及 IAM / VPC 感知安全整合在一起 | 强烈带有 Google Cloud 形状，也会引入相当可观的基础设施和流程开销 |
| Entire | Git 原生会话检查点 | (+) | 把提示词、transcript 和 files-touched 元数据与提交一起存起来，可恢复检查点，又不污染主分支 | 需要团队围绕智能体会话接受 hooks 和元数据纪律 |
总体来看，只要工具能让边界变得可见，或者让上下文可复用，满意度就会上升；一旦它隐藏操作痕迹，或默认了一种用户必须自己逆向出来的云 / 流程模型，满意度就会下降。最清晰的权宜方案是组合式：Berd 包 Goose，Agents CLI 教现有编程智能体工作，Entire 贴在 Git 上，而 Friday 则是在不替换运行时的前提下，给 Claude Code 外面套上记忆和 cron。在企业侧，Citizen SDLC 和快速验证闭环也说明，光选对工具还不够，还必须同时补上责任归属和审阅护栏。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| fx | Vercel Labs，经由 @vercel_dev 发布 | 可直接使用或嵌入的微型原生编程智能体运行框架与 CLI | 给开发者一个更轻、更不锁模型的运行时，用于沙箱、基准和更大的智能体系统 | Zig、AI Gateway、skills、MCP、ACP、WebAssembly | Alpha | post / repo / site |
| Berd | Block 团队，经由 @TFTC21 和 @morganmartn 带出 | 跨项目、技能、工具和模型与智能体协作的桌面工作区 | 减少围绕现有运行时的碎片化界面、provider 配置和上下文处理 | Tauri 2、React 19、Goose、ACP | Beta | post / repo / design |
| Potpie | Potpie 团队，经由 @tom_doerr 传播 | 面向代码库和 SDLC 工作流的活的上下文图谱 | 给智能体提供项目特定的历史、决策和工作流上下文，而不是一个裸 checkout | Python CLI、daemon、graph explorer、GitHub 和 docs 集成、harness skills | 已发布 | post / repo / site |
| Codag | Michael Palmer，经由 @michaelzixizhou 发布 | 面向智能体工具输出的压缩与控制层 | 削减上下文膨胀，并暴露跨智能体的工具 / MCP 使用、延迟和花费 | Tool wrappers、reducer pipeline、analytics、policy layer | 已发布 | post / YC / site |
| Friday | missingus3r，经由 @DanKornas 带出 | 围绕 Claude Code 和 Telegram 搭建的 24/7 个人 AI 助手 | 在不发明自定义运行时的情况下，补上持久记忆、定时任务和外部工具访问 | Claude Code CLI、Telegram MCP、Flask、SQLite、Notion MCP、ElevenLabs、cron | Alpha | post / repo |
| Entire | Entire 团队，经由 @rseroter 传播 | 用 Git 原生方式捕获和检查点化 AI 编程会话 | 在不污染主分支的前提下，把提示词、transcript 和触达文件保存成团队可见的元数据 | Git hooks、checkpoint branch、CLI、worktree 支持 | 已发布 | post / repo / blog |
fx 和 Berd 展示的是两种相反、但互补的策略。fx 把运行框架剥到足够小，方便嵌进任何地方；而 Berd 则在外部运行时之上加了一层更干净的桌面表面，让人能把项目、providers 和上下文都放在一个地方。Friday 则从独立构建者角度，把同一种组合模式又往前推了一步：运行时仍然是 Claude Code，只是在外面补上记忆、渠道和调度。
这种设计取向在 @morganmartn 的描述里（70 个点赞、6 条回复、33,807 次浏览、29 次收藏）说得非常明确：Berd 想成为一个让非工程师也容易上手、并且值得每天打开的工作区，而不是另一个技术上很强、但让人没有亲近感的 wrapper。
Potpie、Codag 和 Entire 都属于第二类构建模式：它们并不想自己成为那个智能体，而是在围绕智能体的层上做产品——上下文图谱、工具输出压缩，以及带检查点的会话历史。这是一个很强的信号，说明围绕智能体的基础设施正在形成独立市场，而不再只是实现细节。
还有一个更偏宣传、但仍然有参考价值的产物，来自 @jack_9947 的说法（46 个点赞、80 条回复、2,567 次浏览、51 次收藏）：他的团队把 GTM 工作组织成了一个由 92 个智能体构成的 marketplace，覆盖获客、定价、RevOps 报表、合作伙伴动作、支持交接和高管汇报。即便这条帖子明显带有销售色彩，那张海报本身仍然很好地说明，团队正在把业务职能拆成几十个狭窄智能体，而不是继续依赖一个通用助手。
6. 新动态与亮点¶
Entire 把智能体式思考变成了一种 Git 产物¶
@rseroter 分享了（1 个点赞、1 条回复、168 次浏览）Entire：它会把提示词、transcript 和触达文件记录到单独的 entire/checkpoints/v1 分支上。公开仓库和博客之所以让它显得值得注意，是因为这个工具并不试图替代 Git 或编程智能体；它做的是把会话产物变成一种可恢复、可搜索的历史，并与正常代码工作并行存在。
单一订阅、单一 CLI、单一模型，开始变成一种严肃的构建模式¶
@DanKornas 分享了（5 个点赞、2 条回复、871 次浏览、9 次收藏）Friday：一个完全建立在 Claude Code 之上的 24/7 助手，只是在外围加上记忆、cron 和 MCP 层。它之所以值得注意，不在于规模有多大，而在于它明确拒绝再引入一层框架，转而把一个现有运行时拉伸成一套持久的个人系统。
AI 参与模式把问题从模型能力，重新拉回到了用户行为¶
@BrianRoemmele 总结了（39 个点赞、8 条回复、5,659 次浏览、25 次收藏）一个研究框架：长期结果并不主要取决于“是否在用 AI”，而是取决于人们会不会验证、质疑、设定问题，而不是被动接受输出。这一点在今天尤其重要，因为当天很多别的推文，本质上也都在讨论如何构建系统，让用户重新回到更高能动性的模式里，而不是让自动化保持流畅却不透明。
7. 机会在哪里¶
[+++] 面向智能体工作的上下文控制基础设施 — Potpie、Codag、Entire 以及围绕 Buzz 的抱怨，其实都在指向同一个缺口：团队需要一层东西，来决定哪些上下文进入模型、哪些内容被做成检查点、哪些东西保持可查询，以及工具路径本身要花多少钱。这个信号很强，因为它在同一天里同时出现在开源仓库、商业发布和实践者痛点中。
[+++] 面向非工程人员软件构建的企业护栏 — Citizen SDLC、“采用很容易，转型并不容易”那张幻灯片，以及 Google 的生命周期栈，都汇聚到了一个非常实际的需求：为 AI 构建的软件提供 request intake、ownership、已配置环境、verification，以及受控变更管理。这个机会很强，因为问题已经有预算、风险责任人，以及多条帖子反复使用的相似语言。
[++] 带显式状态边界、可检查的多智能体工作区 — Grok Bot、Buzz、Berd 和 piotr_jura 的原型都在暗示，人们需要一个地方管理大量智能体、模型和项目，同时不要隐藏工具调用、共享文件系统或恢复状态。这个机会属于中等强度，因为产品正在快速冒出来，但信任与边界问题仍然明显没有解决。
[+] 更高能动性的个人助手系统 — Friday 和 Brian Roemmele 那套研究框架说明，市场可能存在一类助手：既能保留连续性，又能让用户停留在验证、质疑和设定问题的位置，而不是滑向被动的 prompt-and-ship 习惯。这个信号比企业 / 控制层主题更早期，但既有真实构建模式支撑，也有一套清晰的行为理论作背书。
8. 要点总结¶
- 上下文管理是当天最深的控制点。 最强的帖子谈的是 monorepo、共享对话、可移植角色文档和活的上下文图谱，而不是某个模型又赢了另一个模型。(source, source, source)
- 最有意思的新产品，都是在包裹或打磨现有运行时。 fx、Berd、Friday 和 Google 的生命周期工具，都把运行时视作应该被嵌入、包围或“教会”的一层，而不是每次都从零重建的对象。(source, source, source, source)
- 持久自治仍然是缺失的功能。 共享上下文在改善，但人们仍然担心上下文漂移、隐藏的工具调用、模糊的状态共享，以及长时间运行工作必须有人盯着。(source, source, source)
- 企业 AI 推广如今成败都系于验证和责任归属护栏。 当天最主导的运营语言，是 discovery、triage、provisioning、governance、evaluation 和 approval，而不是席位数或泛泛的热情。(source, source, source)
- 围绕工具路径本身，正在形成一个独立市场。 压缩、会话检查点和上下文图谱之所以开始产品化，是因为原始输出、分散产物和不可见历史，如今都已经成了实打实的瓶颈。(source, source, source)