Twitter AI 智能体 - 2026-07-18¶
1. 人们在讨论什么¶
1.1 运行框架工程成了智能体成败的默认解释 (🡕)¶
至少有 6 条保留下来的内容认为，模型质量已经不再是主要变量。这一天最强的帖子认为，真正的差异化如今落在运行框架、验证、记忆和控制层上。相比 7 月 16 日“同一个模型，不同的系统”的表述，7 月 18 日把运行框架工程推到了最前面，并把它和具体清单、角色边界以及运行数据绑在了一起。
@0xCodez 表示（141 点赞、16 回复、15,712 浏览量、215 收藏），Anthropic 的内部栈是模型、运行框架、智能体和上下文，甚至还特别强调“RAG 是反模式。用 grep。”把注意力从模型升级转向文件支撑的记忆和任务专用的运行框架。@sairahul1 认为（134 点赞、18 回复、15,887 浏览量、184 收藏），循环工程真正关心的是触发器、独立检查器、持久记忆和可观测性，而不只是更好的提示词。@neil_xbt 写道（82 点赞、31 回复、4,327 浏览量）：“智能体不难；难的是运行框架。”随后他又把运行框架拆成工具、记忆与状态、约束、验证和编排。
@ParamSiddh 列出了（71 点赞、5 回复、2,977 浏览量、89 收藏）AI 工程师现在需要的具体能力：工具契约、降级模式 UX、检索评估、可观测性、安全工程、多租户隔离和循环预算。@cyrilXBT 补充了（110 点赞、31 回复、11,874 浏览量、62 收藏）一个四层生产智能体模型——模型、运行框架、工具、环境。它给出的数据异常具体：93% 的权限提示会在未细读时直接获批，复杂任务里的澄清比例只有 16.4%，而 Anthropic 团队用 16 个协同智能体造出了一个能编译 Linux 6.9 的 C 编译器，API 成本约为 20,000 美元。
讨论要点： 回复里并没人要求更巧的提示词。他们要的是固定的评审智能体、更便宜的拒绝循环、硬性停止条件、幂等操作、降级模式，以及始终显式存在的人类判断。即便是那条试探“把引导删掉”的讨论串，也立刻有人直接回击：一旦没了引导，可靠性就会下降。
与前日对比： 7 月 16 日把“同一个模型，不同的系统”作为与资源开通摩擦并列的大主题。7 月 18 日则把这个框架推到了中心，并用具名角色、清单和生产指标把它包得更实。
1.2 图结构、记忆和评估，从旁支功能变成了下一条升级路径 (🡕)¶
至少有 7 条保留下来的内容把智能体质量视为状态管理和度量问题。这一天的讨论已经越过了“用循环”这一步，转向显式的图路由、记忆整理和上下文质量打分。
@sairahul1 认为（26 点赞、6 回复、5,990 浏览量、42 收藏），在引用 OpenClaw 创始人 Peter Steinberger 的话之后，循环正在让位于图工程：专门化智能体、分支、记忆、并行工作、条件路由和长时运行状态。@N01ennn 提到（45 点赞、11 回复、1,201 浏览量、31 收藏），Anthropic 那场记忆系统演讲的重点，是 CLAUDE.md、技能、版本控制、哈希、权限、带内记忆限制，以及智能体休眠时对记忆做“做梦式”整理。@coreyhainesco 做了（55 点赞、7 回复、4,558 浏览量、79 收藏）一个第二大脑技能，把采集内容编译成互相链接的维基，并且只依据此前收集过的来源作答。
@omarsar0 重点提到（35 点赞、16 回复、3,406 浏览量、41 收藏）ProofAgent Harness 及其背后的论文，这套方法会按角色清晰度、安全护栏覆盖率、指令一致性、工具 schema 质量、依据充分性、提示注入防护和 token 效率来给上下文质量打分。@nykdotdev 认为（11 点赞、4 回复、636 浏览量、9 收藏），光有日志还不够；Mission Control 要想安全运行多个智能体运行时，就需要任务分派、执行、审查、批准、完结回执和验证证据。
讨论要点： 最强的回复始终在强调，可检查的记忆和可审计的上下文边界。有人要的是用户能直接编辑的记忆；有人说缺的评估目标，就是决策当下可见的那一窗口文件、工具结果和指令；还有人说，引用验证应该对来源谱系去重，而不是把重复 URL 当成独立证据来计数。
与前日对比： 7 月 16 日已经点出了 shell 状态漂移和工作记忆冲突。7 月 18 日则把它上升成图工程、“做梦式”记忆整理、上下文打分准则，以及置于智能体运行时之上的显式控制平面。
1.3 构建者开始把编排、研究和运行时控制打包到模型外围 (🡕)¶
最强的一波构建活动并没有宣称模型更聪明。它们把规划角色、引用验证、共享沙箱和运行时控制打包起来，让智能体在更少手工复制上下文的情况下运行。至少有 8 条保留下来的内容支持这一模式。
@akshay_pachaar 做了（62 点赞、18 回复、7,298 浏览量、83 收藏）一个开源的 CrewAI 编程运行框架，把文件工具当作记忆，并带有子智能体、一次性 VM 沙箱隔离、人工批准和检查点机制。@socialwithaayan 展示了（29 点赞、16 回复、13,855 浏览量）Codex Orchestration：Codex 继续担任根编排器，但把规划、建议和执行交给专门角色，而不是在一个循环里包办一切。
@tom_doerr 提到（17 点赞、4 回复、2,926 浏览量、18 收藏）Claude Code Deep Research Agent，其说明文档特别强调《Graph of Thoughts》、七阶段流程、并行研究角色和引用验证。@DanKornas 介绍了（6 点赞、1 回复、1,061 浏览量、8 收藏）Open Deep Research；LangChain 自己的说明写到，它把工作拆成范围界定、研究和写作三个阶段，并且只在可并行的研究部分使用多智能体。
@ClaudeDevs 描述了（61 点赞、7 回复、22,909 浏览量、20 收藏）Managed Agents：它能在不同模型和提示词之间共享沙箱或凭据库中的凭据；与此同时，@GrokInsider 报道称（55 点赞、3 回复、7,100 浏览量），Grok Build CLI v0.2.103 加入了运行时级控制，例如 require_sha、可配置的 env / cwd 继承、MCP 配置选项，以及更安全的本地 Bash 行为。
讨论要点： 回复更偏好有边界的编排，而不是松散撒开的群体式协作。支持 Codex Orchestration 的人强调，根编排器必须始终掌舵；一条关于 Claude Managed Agents 的回复说，真正的价值在于交接前先把人类思路清理干净；还有一条关于深度研究的回复认为，来源谱系去重比原始引用数量更重要。
与前日对比： 7 月 16 日的构建者主要围绕浏览器工作区、部署界面和资源开通器。7 月 18 日则把打包层往上提，转向编排插件、深度研究智能体和运行时控制平面。
2. 令人困扰的问题¶
记忆层依然会失灵，因为智能体记住了太多杂乱内容，真正的结构却记得不够¶
问题不是“我们需要更多 token”，而是智能体忘掉了该记的东西，却把不该留的保留下来。对 @sairahul1 的一条回复直接要求记忆必须允许人检查、更新、删除和补充。@N01ennn 提到（45 点赞、11 回复、1,201 浏览量、31 收藏），Anthropic 的记忆演讲其实已经在提醒：带内记忆很快会碰到上限，因此需要版本控制、权限，以及“做梦式”整理。@coreyhainesco 做了（55 点赞、7 回复、4,558 浏览量、79 收藏）一个第二大脑技能，正是因为单靠一堆扁平、可搜索的材料还不够；@chenzeling4 提到（1 点赞、42 浏览）Context Mode，其仓库简介主打把工具输出减少 98%，并在多次运行之间保留会话记忆。
严重程度：高。可见的应对方式，是外部记忆层、维基式链接、上下文压缩，以及显式的状态同步，而不是指望更大的上下文窗口自然表现得像持久记忆。这值得直接构建，因为这种痛点既出现在高互动量讨论串里，也出现在互动量不高但落地细节极具体的帖子里。
仅靠日志，依然无法证明任务真的做完、经过审查，或结果正确¶
@nykdotdev 认为（11 点赞、4 回复、636 浏览量、9 收藏），难点已经不再是让智能体动起来，而是弄清到底发生了什么：任务归谁负责、实际执行了什么、审查过什么、哪些地方悄无声息地失败了，以及声称产出的结果是否经过验证。@omarsar0 重点提到（35 点赞、16 回复、3,406 浏览量、41 收藏）一种上下文打分方法，因为薄弱的上下文往往会在后面表现为幻觉、工具误用或暴露于提示注入风险之下；有条回复把问题说得更尖锐：真正的失败往往在“前两步”就开始了——当时系统看到的上下文窗口根本不对。即便是基准测试结果很亮眼的帖子，也招来了同样的抱怨：@XFreeze 下面有条回复说，私有基准测试里 70 题对 69 题，除非任务列表、污染检查和审计轨迹都公开，否则仍然只是营销。
严重程度：高。人们现在的应对方式，是加审查闸门、上下文打分、来源谱系检查和完结回执，但整组内容仍然显示，在“智能体跑过了”和“结果值得信任”之间，还缺了一层。这值得直接构建，因为这个问题横跨编程、研究和多智能体协作。
安全边界和执行边界，依然很容易做错¶
@ParamSiddh 把（71 点赞、5 回复、2,977 浏览量、89 收藏）提示注入防御、数据泄露防护、权限边界、工具预算和终止条件列为标准工程问题，而不是边界情况。@AiCamila_ 发布了（2 点赞、46 浏览）一套安全蓝图，覆盖输入护栏、工具与操作安全、行为控制、输出控制，以及监控或审计。@GrokInsider 报道称（55 点赞、3 回复、7,100 浏览量），Grok Build CLI 加入了 require_sha，避免远程插件跟随可变分支或 tag，同时在目录删除失败后移除了持久本地 shell。公开的 Hugging Face 2026 年 7 月事故披露 则把风险讲得非常具体：一个自治智能体系统利用了数据集处理的执行路径，再用窃取到的凭据继续提权。防守方因此不得不放弃托管前沿模型，因为安全护栏阻止了他们对真实攻击工件做取证分析。
严重程度：高。可见的应对方式，是固定插件版本、默认拒绝式配置、审计日志，以及为事件响应保留开放权重或自托管的后备方案。这值得直接构建，因为痛点已经不再是假设；无论是推文还是外部事故披露，都描述了具体的失效面。
3. 人们期望的功能¶
可检查、可修剪、可同步、能跨会话延续的记忆¶
这里的需求既现实又紧迫：人们想要的不只是更大的上下文窗口，而是可检查、可整理、值得信任的记忆。@sairahul1 下面的回复明确要求用户能更新或删除记忆；@coreyhainesco 展示了（55 点赞、7 回复、4,558 浏览量、79 收藏）一个相互链接的第二大脑，而不是一堆扁平的笔记；@chenzeling4 提到（1 点赞、42 浏览）Context Mode，把它当成在保留会话记忆的同时压缩嘈杂工具输出的一种办法。@AiCamila_ 把（9 点赞、135 浏览）缺失的落地层概括为短期记忆、长期记忆、持久状态、记忆管理和同步。今天已经有一些局部答案，但这一天的时间线仍然显示，“有上下文”和“记得正确”之间依然有缺口。机会：直接。
能把每次运行变成可核验回执的控制平面¶
人们想要的是运行后的证据，而不只是聊天记录。@nykdotdev 认为（11 点赞、4 回复、636 浏览量、9 收藏），智能体运营需要任务分派、执行、审查、批准、完结回执和验证证据；@omarsar0 提到（35 点赞、16 回复、3,406 浏览量、41 收藏）上下文打分，把它视为判断一次智能体运行能否持续可靠的领先指标。就连围绕 @XFreeze 的基准测试讨论，也变成了对可审计任务列表、污染检查和单次成功成本的期待，而不是只看单一排行榜数字。Mission Control 和 ProofAgent Harness 今天已经部分覆盖了这类需求，但紧迫性依然很高，因为痛点横跨编程智能体、研究智能体和多智能体团队。机会：直接。
基于图的编排、清晰的角色边界，以及具备来源谱系感知的研究流程¶
最强的编排愿望不是“更多智能体”，而是更好的智能体拆分方式。@sairahul1 表示（26 点赞、6 回复、5,990 浏览量、42 收藏），图结构之所以正在取代循环，是因为真正的系统需要分支、记忆、条件路由和并行工作。@socialwithaayan 展示了（29 点赞、16 回复、13,855 浏览量）Codex Orchestration：根编排器继续掌舵，而不同角色分别负责规划、审查和执行。@tom_doerr 提到（17 点赞、4 回复、2,926 浏览量、18 收藏），引用验证是各类深度研究仿制项目里缺失的关键一层；@DanKornas 介绍了（6 点赞、1 回复、1,061 浏览量、8 收藏）Open Deep Research，而它自己的博客也提醒，不要把写作这一步并行化。这是一个现实需求，而且已经开始出现直接竞争。机会：直接。
面向插件、工具和自治运行时的默认安全执行层¶
这里想要的，是让危险路径更难走通的默认安全设置，而不是再多一份安全备忘录。@AiCamila_（2 点赞、46 浏览）希望每个生产系统都从分层护栏起步；@GrokInsider 报道称（55 点赞、3 回复、7,100 浏览量），require_sha 是一项真正的 CLI 加固措施；而 Hugging Face 2026 年 7 月事故披露 则说明，当托管安全系统阻碍取证分析时，防守方也需要自托管模型选项。这个需求偏向现实而非情绪：更安全的插件解析、更清晰的权限边界、可逆操作，以及随时能用于事件响应的后备方案。机会：直接。