Twitter AI Agent - 2026-08-16¶
1. 大家在讨论什么¶
1.1 图工程与 Harness 工程成为严肃智能体工作的默认思路（🡕）¶
至少有五条入选内容都把提示词技巧视为入口，而非前沿。反复出现的关键词包括图路由、后端抽象、插件化运行时，以及对文件、沙箱和子智能体的显式控制。与 8 月 15 日相比，讨论已从宽泛的 Harness 原则，转向更具体的运行时形态和公开仓库。
@waynoir 界定（69 个赞、8,448 次浏览、115 个收藏）认为，图工程是继提示词、上下文、记忆、智能体和循环设计之后的下一步；其中最有价值的一条回复澄清说，重点在于基于数据的路由，而不是把固定链路拉得更长。
@cyrilXBT 认为（134 个赞、17 条回复、13,653 次浏览、142 个收藏）表示，Anthropic 那篇关于“图工程”的文章实质性改变了他自己那套系统的响应方式；随附页面则用一条“检索优先”的流水线把这一说法具体化：知识库导入、路由、索引评分、节点检索、图遍历，最后进行推理。
@rohanpaul_ai 报道称（73 个赞、6 条回复、5,355 次浏览、33 个收藏）称，DeepSeek Harness 的 star 数已超过 136k，并将模型、工具、循环、存储、调度和 UI 都做成了可替换插件。公开仓库的 README 也强化了同样的论点：这是一个本地 Web 应用，采用 MIT 许可证、基于 Cordis 的插件架构，并明确标注为开发者预览版。
@hwchase17 介绍了（54 个赞、10 条回复、8,012 次浏览、75 个收藏）从另一个角度说明了同样的转变：Deep Agents 将智能体循环与后端分离，后端负责提供类文件系统操作和可选的代码执行能力，因此同一套 Harness 可以用于本地 TUI、远程沙箱，或不写代码的“伪”后端。
讨论洞察： 最有价值的反驳并不是“图错了”，而是模型可移植性弱于后端可移植性；没有结构的炒作很难让人信服，真正的收益来自让路由与执行过程都可观察、可检查。
与前一天的对比： 8 月 15 日的讨论已经把 Harness 工程视为关键差异化因素。到了 8 月 16 日，讨论进一步落到公开实现层面：插件系统、文件系统抽象，以及图优先的运行时示意图。
1.2 基于文件的记忆与上下文卫生，成为让智能体长期保持实用性的主要方式（🡕）¶
第二组内容认为，竞争层面已不再只是更大的上下文窗口，而在于系统保留什么、存在哪里，以及如何有选择地重新加载。最有代表性的内容把仓库文件、SOP、图记忆层和会话管理命令，连接成了一套统一的操作模型。
@beamnxw 总结了（35 个赞、18 条回复、909 次浏览、23 个收藏）提到了 Anthropic 围绕 /clear、/compact、模型选择、文件引用和上下文检查总结出的六条会话规则。公开的 Claude Code 最佳实践指南 和 会话管理文章 也支持同样的警示：上下文窗口很快就会被填满，越接近填满，性能越会下降；面对新任务时，通常需要开启一个干净的新会话，或改用子智能体，而不是继续往同一段对话里追加内容。
@jordan_ross_8F 展示了（10 个赞、3 条回复、5,256 次浏览、29 个收藏）展示了这种做法在代理机构中的实际落地方式：一个 GitHub 仓库、每个客户一个文件夹、每份 SOP 对应一个技能文件夹、用于周期性工作的 cron 任务，以及供代理日后重新打开的 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 日已经把仓库和文件推到了“记忆载体”的位置。到了 8 月 16 日，讨论进一步给出了操作层面的指导，说明何时该清空、压缩、分支，或把这些记忆外置到图谱支撑的工具中。
1.3 多代理系统正围绕监督、所有权和安全被重新界定（🡕）¶
第三个主题是克制与控制。构建者依然想要并行代理，但讨论重点已经转向：第二个代理在什么情况下才值得引入、共享状态由谁负责，以及如何避免持久化文件或长时间运行的循环变成失去治理的基础设施。与 8 月 15 日强调“监督者”的说法相比，今天的证据对失败模式和企业实践说得更明确。
@AlexFinn 认为（266 个赞、45 条回复、18,507 次浏览、302 个收藏）展示了 Grok Bot 中一个具体的编排器—工作器循环：一个机器人负责让另一个机器人始终围绕任务推进，并定期提出流程改进建议。回复串随即补充了两个现实约束：有人把它称为“经理”，还有人说这种模式之所以有用，是因为它能把枯燥的工作下放给更便宜的子代理。
@monokern 认为（34 个赞、6 条回复、1,948 次浏览、42 个收藏）认为，大多数团队仍应先从一个代理开始，只有在注意力被稀释、多步骤复杂性、专业化需求、天然并行性、高错误成本或模块化要求确实存在时，才增加第二个代理。Anthropic 公开发布的 多智能体系统文章 也持相同观点，并补充了成本层面的考量：多代理设置消耗的 token 往往是单代理方案的 3-10 倍。
@neviannn 分享了（26 个赞，1,385 次浏览，35 个收藏）微软的 lead-agent 实践采用了这样一种模式：各个专门代理只负责狭窄范围内的任务，由中央协调器掌握全局上下文。微软公开的 AI 编排指南 同样将多代理编排置于复杂度阶梯中比直接调用模型和“单代理+工具”更高的位置，而 Conductor 文章 则强调确定性路由和显式的上下文流转。
@rohanpaul_ai 警告称（18 个赞，7 条回复，2,234 次浏览，13 个收藏）指出，Mind Viruses 论文 发现，自我传播的目标可以通过改写可自修改文件而持续存在，而这些文件之后还会重新进入代理的提示词。这使持久记忆从一个生产力话题变成了一个治理话题。
讨论洞察： 最有力的回应聚焦于所有权，而非智能：文件归谁所有，哪个代理只能拿到摘要，共享状态是否只有一个写入者，以及“持久记忆”在多大程度上应被视为敏感配置。
与前一天的比较： 8 月 15 日主张采用监督者和专门代理；到了 8 月 16 日，讨论则通过 token 成本权衡、集中式路由，以及对持久文件传染风险的明确警告，把这些护栏讲得更具体了。
2. 什么让人感到挫败¶
当聊天记录成为唯一记忆时，上下文就会逐渐腐坏¶
最尖锐的不满在于：上下文退化时，代理通常不会明显报错。@beamnxw 总结了（35 个赞，18 条回复，909 次浏览，23 个收藏）提到 Anthropic 的六条规则，正是因为长时间会话会在没有明显故障的情况下逐渐漂移；公开的 会话管理文章 则指出，上下文腐坏会让注意力分散到过多 token 上，并迫使系统进行有损压缩。@SamGCoder 询问（140 个赞，4 条回复，7,207 次浏览，16 个收藏）呼吁针对 300k、600k 和 1M token 的行为设定明确的工作模式，这直接表达了一个不满：当前的会话模型过于粗糙。@jordan_ross_8F 展示了（10 个赞，3 条回复，5,256 次浏览，29 个收藏）总结了常见的应对方式：把记忆移入文件，只加载相关文件夹和 SOP。严重程度：高。值得构建：高。
多代理的收益仍伴随着编排开销和不清晰的所有权¶
这场讨论支持 agentic 方向，但并不天真地忽视成本。@monokern 认为（34 个赞，6 条回复，1,948 次浏览，42 个收藏）指出，第二个代理应当在确有必要时才引入，而不是默认配置；Anthropic 公开的 多智能体指导 则表示，多代理系统消耗的 token 往往是单代理方案的 3-10 倍。@AlexFinn 认为（266 个赞，45 条回复，18,507 次浏览，302 个收藏）主张采用“协调器—工作代理”循环，但最佳回复把它称为 manager，另一条回复则立刻转向成本控制，建议把繁琐工作交给更便宜的模型。@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 次收藏）呼吁提供“平衡”“大型代码库”和“长期调查”模式，并为它们设置不同的上下文上限和压缩行为。Anthropic 公开的 会话管理指南 已经向用户提供 /clear、/compact、回退和子智能体，但这条推文说明，人们希望这些选项被打包成一等公民式的预设。机会：直接。
持久、可检查、可复用的记忆层¶
最强烈的愿望并不是“让模型更聪明”，而是“别再让我一遍遍重新教它”。@jordan_ross_8F 展示了（10 个赞、3 条回复、5,256 次浏览、29 次收藏）提到，一家机构已经在通过把语气、SOP、成功案例和失败案例作为文件存进 GitHub 来解决这个问题。@monokern 汇编（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 替代方案，让每个机器人都能拥有自己的计算机及沙箱选择。需求确实存在，但无论开源还是托管方案，都已在所有权、隔离性和部署便捷性上展开竞争。机会：竞争激烈。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 倾向 | 优势 | 局限 |
|---|---|---|---|---|
| DeepSeek Harness | 智能体运行框架 / 运行时 | (+/-) | 模型、工具、循环、存储和 UI 均可插件化；提供本地 Web 应用；采用 MIT 许可证并支持自托管 | 公开标注为开发者预览版；提示词可移植性以及智能体循环的经济性仍有争议 |
| Deep Agents | 智能体运行框架 / 后端抽象 | (+) | 将智能体循环与文件、沙箱解耦；集成子智能体、Shell 访问、技能和持久化记忆 | 相比单一聊天智能体，需要更明确的后端模型和更强的编排纪律 |
Claude Code 会话管理（/clear、/compact、回溯、子智能体） |
上下文管理方法 | (+/-) | 为用户提供明确的重置、压缩、分支和隔离嘈杂工作的方式 | 压缩会有信息损失，用户仍需决定哪些内容应该在任务之间保留 |
makerskills / social-fetch |
智能体技能 / 操作流程 | (+) | 可安装、以文档为先的技能；social-fetch 可将需要登录才能查看的社交平台帖子转成结构化数据 |
依赖插件配置，以及对第三方技能的信任 |
| LlamaIndex、LangGraph、LightRAG、GraphRAG、cognee | 记忆 / 图谱检索技术栈 | (+) | 公开、可复用的图谱驱动记忆与检索层；GitHub 上的采用信号强劲 | 相比单纯的“提示词 + 文件”工作流，会增加基础设施和检索设计的复杂度 |
| TradingAgents | 领域专用多智能体框架 | (+/-) | 为分析师、研究员、交易员、风控和投资组合等角色提供专门分工；广泛支持不同提供商；基于 LangGraph 构建 | 偏研究导向，运维负担较重；并未定位为直接提供交易建议 |
| SkillSpector 和 Cisco Skill Scanner | 技能安全 / 治理 | (+) | 可扫描代码仓库、zip 文件和技能，识别提示词注入、数据外泄和供应链风险；支持 CI/SARIF | 两个项目都明确警告，自动扫描只是尽力而为，并不能证明安全 |
总体来看，这套工具栈正逐渐收敛为三层：负责控制执行的执行框架、决定哪些信息会被保留下来的记忆层，以及决定哪些内容可以被安全加载的治理层。应对上下文膨胀的常见办法，是把持久知识迁移到代码仓库或图存储中；应对编排蔓延的常见办法，则是明确路由与后端的边界。目前竞争最激烈的是执行框架和记忆层，而技能安全工具仍处于更早期、也更碎片化的阶段。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| makerskills / social-fetch | coreyhaines31 | 可安装的技能包，让智能体能够从 X、LinkedIn、Instagram、TikTok、Reddit 和 HN 抓取结构化数据 | 当社交平台帖子被登录墙或反机器人流程挡住时，智能体工作流就会中断 | 文档优先的技能、浏览器自动化兜底方案、Wayback 兜底方案，兼容 Claude Code/Codex/Cursor | 已发布 | 仓库, 网站, 文章 |
| DeepSeek Harness | DeepSeek AI | 开源智能体执行框架，模型、工具、循环、存储、调度和 UI 都以插件形式提供 | 团队希望能替换执行载体和策略，而不必重建整套智能体技术栈 | TypeScript、Cordis、插件架构、本地 Web UI | Beta | 仓库, 网站, 文章 |
| Deep Agents | LangChain | 开箱即用的智能体执行框架，内置子智能体、文件系统访问、Shell 访问、技能和持久化记忆 | 构建者需要一套统一循环，既能对接本地磁盘、远程沙箱，也能连接非编码后端 | Python、LangGraph、可插拔后端、LangSmith、Shell/文件系统工具 | 已发布 | 代码库, 文档, 文章 |
| 以代码仓库为原生载体的代理机构运营模式 | @jordan_ross_8F | 在一个 GitHub 代码仓库中统一放置客户文件夹、品牌文件、由 SOP 支撑的技能和 cron 作业 | 聊天原生记忆无法保留流程、品牌背景或可复用的失败案例 | GitHub、Markdown SOP、cron 作业、Claude Code/Codex/Cursor 风格终端 | 已发布 | 文章 |
| TradingAgents | TauricResearch | 多智能体金融交易框架，包含分析师、研究员、交易员、风控和投资组合管理等角色 | 交易工作流需要角色专业分工、检查点和评估，而不是依赖单一的大一统提示词 | Python、LangGraph、多提供商 LLM 支持、Docker、Ollama、金融数据供应商 | 已发布 | 代码库, 论文, 文章 |
| Rakazo | elie222 | 一种自托管的 Grok Bot 替代方案：每个机器人都有自己的计算机、记忆、例程和历史记录 | 用户希望代理拥有自己的算力和沙箱，而不是受制于封闭供应商的控制平面 | TypeScript、React、Electron、Expo、Hono、Postgres、Graphile Worker、Docker/E2B 沙箱 | Beta | 代码库, 文章 |
最反复出现的构建触发因素，并不是抽象意义上的“自主性”，而是围绕记忆、执行和信息摄取的基础设施缺失。@coreyhainesco 分享（211 个赞、16 条回复、15,657 次浏览、389 次收藏）做了一个社交内容摄取技能，因为代理默认仍无法稳定读取社交平台帖子；而 @jordan_ross_8F 展示（10 个赞、3 条回复、5,256 次浏览、29 次收藏）则指出，代理机构的运营也正围绕文件夹、SOP 和 cron 作业被重新搭建，原因相同：重要上下文需要一个可长期承载的位置。
第二个反复出现的模式，是对 harness 的明确设计。@rohanpaul_ai 报告（73 个赞、6 条回复、5,355 次浏览、33 次收藏）将 DeepSeek Harness 做成一个插件密集型控制平面，而 @hwchase17 描述（54 个赞、10 条回复、8,012 次浏览、75 次收藏）则将 Deep Agents 做成一个可与后端分离的循环。在这两种情况下，真正的差异都不在于提示词更好，而在于规划、文件、权限和执行之间的边界更清晰。
@tom_doerr 分享（6 个赞、1 条回复、2,839 次浏览、16 次收藏）是 Harness Books，一个文档项目：它把 harness 设计中的选择沉淀为两本公开书籍，分别关于 Claude Code 和 Codex。这让那个元模式变得更明确：团队想要的是可复用的运行时方法论，而不只是每周又发布一个新框架。
第三个模式，是面向特定领域或界面的专业化。@quantscience_ 分享（24 个赞、2 条回复、3,379 次浏览、32 次收藏）推出了面向金融领域的 TradingAgents，@RoundtableSpace 分享（37 个赞、7 条回复、3,493 次浏览、15 个收藏）是用于 UI 规划的 Sleek 移动应用设计技能；以及 @Granite0x 分享（17 个赞、2 条回复、509 次浏览、14 个收藏），即面向自托管 bot 电脑的 Rakazo。它们的共同做法，是收窄工作流范围，而不是承诺提供一个无所不能的通用智能体。
6. 新动态与亮点¶
技能安全成为一个独立且清晰可见的产品类别¶
@bibryam 整理（12 个赞、801 次浏览、19 个收藏）列出了十个用于保障智能体技能安全的开源项目，涵盖安装前扫描、供应链控制、运行时治理和沙箱隔离。这一点之所以重要，是因为其底层代码仓库并非玩具示例：SkillSpector 表示，它可扫描 17 个类别中的 69 种漏洞模式，并引用研究称，26.1% 的技能包含漏洞，5.2% 显示出可能的恶意意图；Cisco Skill Scanner 则结合静态分析、行为分析和基于 LLM 的分析，但也明确警告，“未发现问题”并不能证明安全。一个显著变化是，人们不再把技能视为无害的提示片段，而是将其当作需要独立安全工作流的可安装软件。
持久化记忆从生产力功能变成了攻击面¶
@rohanpaul_ai 强调（18 个赞、7 条回复、2,234 次浏览、13 个收藏）提到了 Mind Viruses paper，该研究考察了会通过改写智能体可读取文件而持续存在的自我传播目标。公开论文摘要和推文都指向同一个实际教训：如果 SOUL.md 这类文件，或其他可自我修改的记忆文档，会被重新加载进后续提示，那么它们的性质就更像特权配置，而不是普通无害的笔记。其值得关注之处在于，它把当天两个最大的主题——持久化记忆和多智能体协同——与一种具体的安全失效模式联系了起来，而不只是停留在假设层面。
7. 机会在哪里¶
[+++] Inspectable context and memory control — Evidence appeared in sections 1-3 and 5: people are already compensating with repo folders, SOP files, /clear, /compact, and graph-backed memory stacks, yet @SamGCoder 仍然明确 提问，以获得更好的工作模式。最大的机会，在于构建一种系统，帮助用户决定该保留什么、该总结什么、该遗忘什么，同时不掩盖背后的判断逻辑。
**+++］ 技能与记忆供应链安全** — ［Mind Viruses paper 的组合、SkillSpector 和 Cisco Skill Scanner 同时体现出需求的存在和技术上的紧迫性。市场信号之所以强烈，是因为威胁关联的是常见的智能体工作流——安装技能和重新加载记忆文件——而不是罕见的红队边缘案例。
++］ 面向公共网络、可供智能体读取的摄取** — ［makerskills / social-fetch 之所以存在，是因为社交媒体帖子、登录墙和脆弱的网页界面仍在破坏智能体工作流。这个机会更适合被视为中等机会，而非一片蓝海，因为开发者已经在推出点状解决方案；但无论是研究、监控还是操作人员工作流，相关需求都很广泛。++］ 确定性编排与后端可移植性** — ［Deep Agents、DeepSeek Harness、Anthropic 的 多智能体指导，以及 Microsoft 的 编排指南，都收敛到同一个需求：显式路由、边界清晰的专用代理，以及可分离的执行后端。市场仍然留有空间，去做一类产品，让这些模式更易落地，同时不必让用户直接面对底层 harness 的复杂性。
**+］ 先设计后构建的智能体工作流** — ［Sleek Agent Skills 及其周边回复表明，大家对“先拿到可编辑界面、再生成代码”很感兴趣。这个信号出现得比记忆和安全两条主线更早，但它是一个很具体的切入口：在这类狭窄工作流上，专门化产品可能胜过通用编码代理。
8. 要点¶
- 重心已经从提示词转向 harness。 最有分量的帖子讨论的是图路由、插件化运行时和后端抽象，而不只是提示词本身的写法。（来源）
- 团队正把文件和代码仓库当作持久记忆层，因为聊天会话仍无法稳定提供这种能力。 最明确的证据来自 Anthropic 关于会话卫生的指导、以仓库为原生载体的代理工作流，以及公开的图记忆技术栈。（来源）
- 人们对多代理的热情正在接受成本与控制的筛选。 构建者依然想要编排器—工作器循环，但公开指导强调的是：何时第二个代理值得付出 3-10 倍的协同开销，以及共享状态应由谁持有。（来源）
- 技能安装和持久记忆如今已是治理问题，而不只是便利功能。 安全扫描器和《Mind Viruses》论文都指向同一个暴露面：可复用的文件和技能，可能在无声无息中塑造代理后续的行为。（来源）
- 最具体的构建成果都是狭窄的基础设施切口，而不是万能超级代理。 社交内容摄取、交易编排、移动端 UI 设计，以及自托管机器人计算机，解决的都是单一、边界明确的工作流，并配有显式工具。（来源）