Twitter AI 智能体 - 2026-08-16¶
1. 人们在讨论什么¶
1.1 图结构与运行框架工程成了严肃智能体工作的默认思路 (🡕)¶
至少有 5 条入选内容都把提示词技巧视为入口,而不是前沿所在。反复出现的词是图路由、后端抽象、插件化运行时,以及对文件、沙箱和子智能体的显式控制。和 8 月 15 日相比,讨论已经从宽泛的运行框架原则,转向更具体的运行时形态和公开仓库。
@waynoir 提出(69 个点赞、8,448 次浏览、115 次收藏),图工程是继提示词、上下文、记忆、智能体和循环设计之后的下一步;最有价值的一条回复则澄清,重点是依赖数据的路由,而不是更长的固定链条。
@cyrilXBT 认为(134 个点赞、17 条回复、13,653 次浏览、142 次收藏),Anthropic 的《graph engineering》笔记,实质性改变了他自己那套配置的响应方式;配图页面也把这个说法讲得很具体,展示了一条以检索优先的流水线:资料库接入、路由、索引评分、节点检索、图遍历以及最终推理。

@rohanpaul_ai 提到(73 个点赞、6 条回复、5,355 次浏览、33 次收藏),DeepSeek Harness 已经突破 136k stars,并把模型、工具、循环、存储、调度和 UI 都暴露成可替换插件。公开仓库的 README 也强化了同样的判断:它是一个本地 Web 应用,采用 MIT 许可,基于 Cordis 的插件架构,而且明确标注为开发者预览版。

@hwchase17 从另一个角度描述了同样的转变(54 个点赞、10 条回复、8,012 次浏览、75 次收藏):Deep Agents 把智能体循环和负责暴露类文件系统操作、以及可选代码执行的后端拆开,因此同一套运行框架既可以面向本地 TUI,也可以对接远程沙箱,甚至面向不写代码的“伪”后端。
讨论要点: 最有价值的反驳不是“图结构错了”。真正的重点是,模型的可移植性弱于后端的可移植性,没有结构支撑的炒作很难让人信服,真正的收益来自让路由和执行过程可检查。
与前日对比: 8 月 15 日已经把运行框架工程视为差异化所在。8 月 16 日则进一步推进到公开方案:插件系统、文件系统抽象,以及图优先的运行时示意图。
1.2 基于文件的记忆与上下文卫生,成了让智能体长期保持可用的主要办法 (🡕)¶
第二个讨论簇认为,竞争层已经不只是更大的上下文窗口。真正关键的是系统保留什么、保留在哪里,以及它会如何有选择地重新加载。最强的几条内容把 repo 文件、SOP、图记忆层和会话管理命令串成了一种完整的运行模型。
@beamnxw 总结了 Anthropic 围绕 /clear、/compact、模型选择、文件引用和上下文检查提出的 6 条会话规则(35 个点赞、18 条回复、909 次浏览、23 次收藏)。公开的 Claude Code 最佳实践指南 和 会话管理文章 都支持同样的提醒:上下文窗口会很快塞满,越满性能越差,而新任务往往需要一个干净会话或子智能体,而不是继续往里堆聊天记录。

@jordan_ross_8F 展示了 这在一家代理机构里是怎么落地的(10 个点赞、3 条回复、5,256 次浏览、29 次收藏):一个 GitHub repo、每个客户一个文件夹、每条 SOP 有一个技能文件夹、用 cron jobs 跑周期性工作,再加上之后还能让智能体重新打开的 winners 和 losers 文件。他在引用讨论串里把更深一层的判断说得很明白:终端会只挑出任务真正需要的那几个文件,而聊天附件和检索桶则会在不知不觉中膨胀或漂移。

@SamGCoder 提出(140 个点赞、4 条回复、7,207 次浏览、16 次收藏),希望能有和不同上下文上限及压缩行为绑定的显式工作模式:Balanced 用于普通任务,Large Codebase 用于保留更多历史,Long-Running Investigation 用于代码考古和逆向工程。这个请求之所以成立,正因为会话拓扑如今已经成为用户能感知到的产品表面。
@monokern 整理了 一套知识图谱记忆栈(35 个点赞、14 条回复、1,019 次浏览、21 次收藏),包括 LlamaIndex、LangGraph、LightRAG、GraphRAG 和 cognee,把持久化智能体记忆打包成可复用基础设施,而不是一次性的提示词技巧。
讨论要点: 回复把问题说得更尖锐了:/clear 只有在团队知道该保留什么时才真正有用,而 losers 文件夹可能和 winners 一样重要,否则智能体只会不断重复上一次成功的模式。
与前日对比: 8 月 15 日已经在推动把 repo 和文件当作记忆表面。8 月 16 日则补上了操作层指导:何时清空、何时压缩、何时分支,以及何时把记忆外置到图支撑工具里。
1.3 多智能体系统的讨论重新收敛到监督、归属与安全 (🡕)¶
第三个主题是克制加控制。构建者依然想要并行智能体,但重点已经转向:第二个智能体什么时候才值得引入、共享状态该由谁负责,以及如何避免持久化文件或长循环变成无人治理的基础设施。和 8 月 15 日偏重监督者模式的讨论相比,今天的证据对失效模式和企业场景讲得更直白。
@AlexFinn 主张 在 Grok Bot 里采用一个明确的编排者-执行者循环(266 个点赞、45 条回复、18,507 次浏览、302 次收藏):其中一个机器人负责让另一个机器人别跑偏,并定期提出流程改进建议。回复串马上补上了两个现实约束:有人说这其实“像个经理”,也有人说这个模式之所以有用,是因为它能把枯燥活分派给更便宜的子智能体。
@monokern 认为(34 个点赞、6 条回复、1,948 次浏览、42 次收藏),大多数团队仍应该从单智能体开始,只有在注意力被稀释、多步骤复杂度、专业化、天然并行性、错误代价高或模块化需求出现时,才去增加第二个智能体。Anthropic 公开的 多智能体系统文章 也给出了同样判断,并补上了成本维度:多智能体配置往往要比单智能体方案多消耗 3-10 倍 token。

@neviannn 分享了 Microsoft 的主智能体操作手册(26 个点赞、1,385 次浏览、35 次收藏),其中专职智能体都保持狭窄范围,中央编排器则持有全局上下文。Microsoft 公开的 AI 编排指南 同样把多智能体编排放在复杂度阶梯中高于直接模型调用和带工具的单智能体,而 《Conductor》文章则强调确定性路由和显式上下文流。

@rohanpaul_ai 警告(18 个点赞、7 条回复、2,234 次浏览、13 次收藏),《Mind Viruses》论文 发现,自我传播的目标可以通过重写那些之后会重新进入智能体提示词的可自修改文件而持续存在。这样一来,持久记忆就不再只是效率话题,也成了治理话题。
讨论要点: 最强的回应谈的不是智能水平,而是归属:谁拥有某个文件、哪个智能体只能拿到摘要、共享状态是否该只有一个写入者,以及“持久记忆”到底有多少应该被视为敏感配置。
与前日对比: 8 月 15 日还在论证监督者和专职智能体的重要性。8 月 16 日则把护栏讲得更具体了:token 成本取舍、集中式路由,以及持久化文件传播风险的明确警告。
2. 令人困扰的问题¶
聊天历史一旦成了唯一记忆,上下文就会腐坏¶
最尖锐的挫败感在于,上下文退化时,智能体通常不会明显报错。@beamnxw 总结 Anthropic 的 6 条规则(35 个点赞、18 条回复、909 次浏览、23 次收藏),正是因为长会话会在不明显坏掉的情况下慢慢漂移,而公开的 会话管理文章 也指出,上下文腐坏会把注意力摊薄到太多 token 上,并迫使系统做有损压缩。@SamGCoder 要求(140 个点赞、4 条回复、7,207 次浏览、16 次收藏)提供与 300k、600k 和 1M-token 行为绑定的显式工作模式,这其实是在直接抱怨现在的会话模型过于粗糙。@jordan_ross_8F 展示了 一种应对方式(10 个点赞、3 条回复、5,256 次浏览、29 次收藏):把记忆搬进文件里,然后只加载所需文件夹和 SOP。严重程度:高。值得为此构建:高。
多智能体的收益仍伴随编排开销和不清晰的归属¶
讨论整体支持智能体化,但对成本并不天真。@monokern 认为(34 个点赞、6 条回复、1,948 次浏览、42 次收藏),第二个智能体应该靠需求赢得位置,而不是默认就加上;Anthropic 公开的 多智能体指引 也指出,多智能体系统的 token 消耗经常是单智能体方案的 3-10 倍。@AlexFinn 主张(266 个点赞、45 条回复、18,507 次浏览、302 次收藏)采用编排者-执行者循环,但最好的回复把它叫作经理,另一条回复则马上把重点转到成本控制:把枯燥活交给更便宜的模型。@hwchase17 从构建者一侧描述了 这种应对方式(54 个点赞、10 条回复、8,012 次浏览、75 次收藏):把“大脑”和“手脚”拆开,让文件操作可插拔,并避免预设每个智能体都必须有代码执行能力。严重程度:中高。值得为此构建:高。
持久化的技能和记忆文件,如今成了安全暴露面¶
安全担忧已经从单次聊天里的提示词注入,转向会被写进可复用文件的内容。@rohanpaul_ai 警告(18 个点赞、7 条回复、2,234 次浏览、13 次收藏),《Mind Viruses》论文 发现,恶意载荷会靠诱导智能体重写持久化文件来传播,而这些文件之后又会重新进入未来的提示词。@bibryam 整理了(12 个点赞、801 次浏览、19 次收藏)正是针对这个问题的开源扫描器,而公开的 SkillSpector README 引用研究称,26.1% 的技能包含漏洞,5.2% 显示出可能的恶意意图;Cisco Skill Scanner 也明确写道,一次干净的扫描并不能证明某个技能就是安全的。人们现在的应对方式包括基线、SARIF 报告、人工审查,以及最小权限安装闸门。严重程度:高。值得为此构建:高。
3. 人们期望的功能¶
能匹配任务类型的上下文模式,而不是单一的通用会话模型¶
最明确的直接诉求,是让模式选择能够匹配任务形态。@SamGCoder 提出(140 个点赞、4 条回复、7,207 次浏览、16 次收藏),希望有 Balanced、Large Codebase 和 Long-Running Investigation 这样的模式,分别适配不同的上下文上限和压缩行为。Anthropic 公开的 会话管理指南 已经给了用户 /clear、/compact、rewind 和子智能体,但这条推文说明,人们希望这些选择被打包成一等公民式的预设。机会:直接。
既可检查又可复用的持久记忆层¶
最强烈的愿望不是“把模型变得更聪明”,而是“别再让我反复教它同样的东西”。@jordan_ross_8F 展示了 一家代理机构已经在用这种方式解决问题(10 个点赞、3 条回复、5,256 次浏览、29 次收藏):把语气风格、SOP、winners 和 losers 都当作文件存进 GitHub。@monokern 整理了 一套 repo 栈(35 个点赞、14 条回复、1,019 次浏览、21 次收藏),包括 LlamaIndex、LangGraph、LightRAG、GraphRAG 和 cognee,这说明人们已经在为这一层挑选方案。这个需求是务实的,不是愿景式的:把有用结果留下来,按需重新加载,并让人类能够检查智能体学到了什么。机会:直接。
可扫描、可版本化、也能安全遗忘的技能供应链¶
第二个强需求,是治理哪些技能和记忆允许长期保留。@bibryam 整理了(12 个点赞、801 次浏览、19 次收藏)专门面向智能体技能的扫描器、包管理器和治理工具,而 @rohanpaul_ai 警告(18 个点赞、7 条回复、2,234 次浏览、13 次收藏),持久化文件可能会变成传播通道。这是一个现实需求,但已经处于竞争赛道:多个扫描项目都已存在,而且没有一个声称自己覆盖完美。机会:竞争。
智能体自有或自带的计算环境¶
人们还想要那种能保有自己工作区、又不会把用户锁进单一托管计算机的智能体。@hwchase17 描述了 一些后端(54 个点赞、10 条回复、8,012 次浏览、75 次收藏):可以是本地磁盘、数据库、对象存储,也可以是远程沙箱;@Granite0x 分享了(17 个点赞、2 条回复、509 次浏览、14 次收藏)Rakazo,这是一个自托管的 Grok Bot 替代品,每个 bot 都有自己的计算机和沙箱选项。需求确实存在,但开放和托管方案都已经围绕所有权、隔离性和部署难度展开竞争。机会:竞争。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| DeepSeek Harness | 智能体运行框架 / 运行时 | (+/-) | 模型、工具、循环、存储和 UI 都可插件化;本地 Web 应用;MIT 许可且可自托管 | 公开标注为开发者预览版;提示词可移植性和智能体循环的成本收益仍有争议 |
| Deep Agents | 智能体运行框架 / 后端抽象 | (+) | 把智能体循环与文件、沙箱解耦;内置子智能体、shell 访问、技能和持久记忆 | 相比单聊天智能体,需要更显式的后端模型和更强的编排纪律 |
Claude Code 会话管理(/clear、/compact、rewind、subagents) |
上下文管理方法 | (+/-) | 让用户能明确地重置、压缩、分支和隔离嘈杂工作 | 压缩有损,用户仍得决定跨任务该保留什么 |
makerskills / social-fetch |
智能体技能 / 运维者工作流 | (+) | 可安装、文档优先的技能;social-fetch 能把有登录墙的社交帖子转成结构化数据 |
依赖插件配置,也要求用户信任第三方技能 |
| LlamaIndex, LangGraph, LightRAG, GraphRAG, cognee | 记忆 / 图检索技术栈 | (+) | 公开、可复用、由图支撑的记忆与检索层;GitHub 采用信号强 | 相比单纯的提示词加文件工作流,会增加基础设施和检索设计复杂度 |
| TradingAgents | 领域专用多智能体框架 | (+/-) | 拥有分析师、研究员、交易员、风险和组合管理等专职角色;提供广泛的提供商支持;基于 LangGraph | 更偏研究且运维负担重;并不把自己定位成直接的交易建议 |
| SkillSpector and Cisco Skill Scanner | 技能安全 / 治理 | (+) | 能扫描 repo、zip 和 skills 中的提示词注入、数据外泄和供应链风险;支持 CI/SARIF | 两个项目都明确提醒,自动扫描只是尽力而为,不能当作安全证明 |
| Rakazo | 自托管 bot 计算机 / 沙箱运行时 | (+/-) | 支持自带模型和沙箱;每个 bot 都有自己的讨论串、计算机、记忆和历史 | 仍是早期 Beta,本地配置更重,需要 Docker、Postgres 以及认证 / 沙箱配置 |
整体来看,工具栈正在收敛为三层:控制执行的运行框架、决定什么能留下来的记忆层,以及决定什么加载起来才安全的治理层。面对上下文膨胀,最常见的绕行方式是把持久知识搬进 repo 或图存储;面对编排蔓延,最常见的做法则是把路由和后端边界讲清楚。竞争压力目前最大的是运行框架层和记忆层,而技能安全工具还更早期、也更分散。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| makerskills / social-fetch | coreyhaines31 | 可安装的技能包,让智能体从 X、LinkedIn、Instagram、TikTok、Reddit 和 HN 拉取结构化数据 | 当社交帖子被登录墙或反机器人流程挡住时,智能体工作流就会断掉 | 文档优先技能、浏览器自动化兜底、Wayback 兜底、兼容 Claude Code/Codex/Cursor | 已发布 | repo, site, post |
| DeepSeek Harness | DeepSeek AI | 开源智能体运行框架,模型、工具、循环、存储、调度和 UI 都是插件 | 团队想在不重建整套智能体栈的前提下切换执行表面和策略 | TypeScript、Cordis、插件架构、本地 Web UI | Beta | repo, site, post |
| Deep Agents | LangChain | 内置齐全的智能体运行框架,包含子智能体、文件系统访问、shell 访问、技能和持久记忆 | 构建者需要一个循环,同时能对接本地磁盘、远程沙箱或非编程后端 | Python、LangGraph、可插拔后端、LangSmith、shell / 文件系统工具 | 已发布 | repo, docs, post |
| Repo 原生代理机构运营模型 | @jordan_ross_8F | 在一个 GitHub repo 里放客户文件夹、品牌文件、SOP 驱动技能和 cron jobs | 聊天原生记忆留不住流程、品牌上下文和可复用失败案例 | GitHub、markdown SOP、cron jobs、类 Claude Code/Codex/Cursor 的终端 | 已发布 | post |
| TradingAgents | TauricResearch | 面向金融交易的多智能体框架,包含分析师、研究员、交易员、风险和组合管理角色 | 交易工作流需要角色专业化、检查点和评估,而不是一个巨大的单体提示词 | Python、LangGraph、多提供商 LLM 支持、Docker、Ollama、金融数据提供商 | 已发布 | repo, paper, post |
| Sleek Agent Skills | sleekdotdesign | 让编程智能体在动手写代码前,先用自然语言设计并预览移动 UI 的技能 | 构建者想先有设计再开始写代码,而不是边写边瞎猜布局 | Markdown 智能体技能、Sleek API、托管设计工具 | 已发布 | repo, site, post |
| Rakazo | elie222 | 自托管的 Grok Bot 替代品,每个 bot 都有自己的计算机、记忆、例程和历史 | 用户想要由智能体持有的计算资源和沙箱,而不是被封闭厂商控制平面绑定 | TypeScript、React、Electron、Expo、Hono、Postgres、Graphile Worker、Docker/E2B 沙箱 | Beta | repo, post |
最反复出现的构建动因,并不是抽象的“自治”,而是记忆、执行和摄取周边的基础设施缺口。@coreyhainesco 分享了 一个社交内容摄取技能(211 个点赞、16 条回复、15,657 次浏览、389 次收藏),因为智能体默认仍然无法稳定读取社交帖子;@jordan_ross_8F 展示了 代理机构运营是如何围绕文件夹、SOP 和 cron jobs 被重建的(10 个点赞、3 条回复、5,256 次浏览、29 次收藏):原因是一样的,重要上下文需要一个持久的家。
第二个反复出现的模式,是显式的运行框架设计。@rohanpaul_ai 把 DeepSeek Harness 描述成一个重插件的控制平面(73 个点赞、6 条回复、5,355 次浏览、33 次收藏),而 @hwchase17 把 Deep Agents 描述成一个可以与后端分离的循环(54 个点赞、10 条回复、8,012 次浏览、75 次收藏)。这两者的区分点都不是提示词更好,而是规划、文件、权限和执行之间的边界更清晰。
@tom_doerr 分享了 《Harness Books》(6 个点赞、1 条回复、2,839 次浏览、16 次收藏),这是一个文档项目,把运行框架设计选择整理成两本关于 Claude Code 和 Codex 的公开书。这把更高一层的模式说得很明白:团队想要的是可复用的运行时方法论,而不是每周又来一个新框架发布。

第三个模式是领域或界面专业化。@quantscience_ 分享了 面向金融的 TradingAgents(24 个点赞、2 条回复、3,379 次浏览、32 次收藏),@RoundtableSpace 分享了 Sleek 的 design-mobile-apps 技能,用于 UI 规划(37 个点赞、7 条回复、3,493 次浏览、15 次收藏),而 @Granite0x 分享了 用于自托管 bot 计算机的 Rakazo(17 个点赞、2 条回复、509 次浏览、14 次收藏)。这些项目的共同动作,都是把工作流收窄,而不是承诺一个通用万能智能体。


6. 新动态与亮点¶
技能安全开始成为一个独立且可见的产品类别¶
@bibryam 整理了 10 个面向智能体技能安全的开源项目(12 个点赞、801 次浏览、19 次收藏),覆盖安装前扫描、供应链控制、运行时治理和沙箱隔离。之所以重要,是因为这些底层 repo 并不是玩具示例:SkillSpector 表示它能扫描 17 个类别中的 69 种漏洞模式,并引用研究称 26.1% 的技能包含漏洞、5.2% 显示出可能的恶意意图;Cisco Skill Scanner 则结合静态、行为和基于 LLM 的分析,但也明确提醒,“没有发现问题”并不等于安全。最值得注意的变化是,skills 已经不再被当成无害的提示词片段,而是被当成需要独立安全工作流的可安装软件。

持久记忆从效率功能变成了攻击面¶
@rohanpaul_ai 强调了 《Mind Viruses》论文(18 个点赞、7 条回复、2,234 次浏览、13 次收藏),该论文研究的是通过重写智能体可读文件而持续存在的自我传播目标。公开论文摘要和推文都指向同一个现实教训:像 SOUL.md 这样的文件,或其他可自修改的记忆文档,如果会被重新加载进未来提示词,就更像特权配置,而不是无害笔记。之所以值得注意,是因为它把当天两大主题——持久记忆和多智能体协作——都连接到了一个具体的安全失效模式,而不是停留在假设层面。
7. 机会在哪里¶
[+++] 可检查的上下文与记忆控制 —— 第 1-3 节和第 5 节都给出了这些证据:人们已经在用 repo 文件夹、SOP 文件、/clear、/compact 和图支撑的记忆栈来补位,但 @SamGCoder 仍明确提出需要更好的工作模式。最强的机会,是做出一套系统,帮助用户决定该保留什么、该摘要什么、该遗忘什么,而且不把这套逻辑藏起来。
[+++] 技能与记忆的供应链安全 —— 《Mind Viruses》论文、SkillSpector 和 Cisco Skill Scanner 的组合,同时说明了需求强度和技术紧迫性。这个市场信号很强,因为威胁绑定的是安装技能和重新加载记忆文件这样的日常智能体工作流,而不是少见的红队边界案例。
[++] 面向公共 Web 的智能体可读摄取层 —— makerskills / social-fetch 之所以存在,是因为社交帖子、登录墙和脆弱的 Web 表面仍然会把智能体工作流卡住。这个机会属于中等强度而不是纯绿地,因为构建者已经在交付一些点状方案,但研究、监控和运维工作流里的需求面依然很广。
[++] 确定性编排与后端可移植性 —— Deep Agents、DeepSeek Harness、Anthropic 的多智能体指引以及 Microsoft 的 编排指南 都收敛到了同一个需求:显式路由、范围收紧的专职智能体,以及可分离的执行后端。市场仍然有空间去做那些更容易采用这些模式、又不把用户直接暴露在原始运行框架复杂度前的产品。
[+] 先设计后构建的智能体工作流 —— Sleek Agent Skills 以及围绕它的回复表明,人们确实对“先拿到可编辑的界面,再生成代码”这件事感兴趣。这个信号还早于记忆和安全主题,但它是一个明确切口:在窄工作流里,产品完全可能比通用编程智能体做得更好。
8. 要点总结¶
- 重心已经从提示词转向运行框架。 最强的帖子讲的是图路由、插件化运行时和后端抽象,而不只是提示词写法。(source)
- 团队正把文件和 repo 当作持久记忆层,因为聊天会话仍无法稳定提供这一层。 最清晰的证据来自 Anthropic 的会话卫生指引、repo 原生代理机构工作流,以及公开的图记忆栈。(source)
- 人们对多智能体的热情,正在被成本与控制问题重新筛选。 构建者依然想要编排者-执行者循环,但公开指引强调的是,什么时候第二个智能体值得付出 3-10 倍的协调开销,以及共享状态该如何归属。(source)
- 技能安装和持久记忆如今是治理问题,不只是便利功能。 安全扫描器和《Mind Viruses》论文都指向同一个面:可复用文件和技能会悄悄塑造之后的智能体行为。(source)
- 最具体的构建成果,是狭窄但明确的基础设施切口,而不是通用超级智能体。 社交内容摄取、交易编排、移动 UI 设计和自托管 bot 计算机,解决的都是边界清晰的单一工作流。(source)