Twitter AI Agent - 2026-08-14¶
1. 人们在讨论什么¶
1.1 智能体工程开始被整理成可教授的技术栈和课程 (🡕)¶
至少有 3 个高信号项目，把智能体工作当成一门有名称、也有稳定技能栈的明确学科，而不是松散的提示词手艺。最强的几条帖子收敛到同一组要素：记忆、上下文工程、工具、触发器、权限、评估，以及仓库级控制。今天变化的不只是热情，而是封装方式：技能地图、配方和完整课程，让智能体工程看起来像是团队可以系统训练的东西。
@AndrewYNg 分享了（2,308 个赞、75 条回复、143,316 次浏览、3,934 次收藏）“AI Engineering 中最重要技能的地图”；Andrew Ng 在一条回复里又说，这件事会“远不止一门课程”，把它框定为 DeepLearningAI 围绕面向就业的 AI 工程技能所做的更大推进，而不是一次性课程。
@nicbstme 概括了（304 个赞、9 条回复、35,821 次浏览、551 次收藏）一套完整的智能体产品配方：记忆、上下文工程、技能、工具 / MCP、运行时循环、事件触发器、信任 / 权限，以及评估。下面那条引用推文把这个想法又往前推了一步，认为前沿方向是能被事件唤醒的主动式后台智能体，而真正的竞争点，是能否在每用户成本可行的前提下拿到高质量上下文和有用动作。
@beamnxw 推荐了（44 个赞、16 条回复、1,296 次浏览）《Learn Harness Engineering》这门免费课程，面向以 Codex、Claude Code 和智能体开发为重点的团队；截图也解释了它为什么能引发共鸣：课程讨论为什么能力很强的智能体仍会失败、为什么仓库必须成为系统记录源、为什么长时任务会丢失连续性，以及为什么智能体会越界或收尾不到位。
讨论要点： 这一簇里最有价值的一条回复来自 @mrlaraibkhan，他对 Nicolas Bustamante 说：“人人都把收集这部分做出来了，却把遗忘这部分跳过去了。” 这就把“记忆”从存储问题，转成了保留策略问题。
与前日对比： 8 月 13 日已经把运行框架和技能当成封装层。8 月 14 日则进一步推进到了明确的技能地图、课程体系和技术栈配方。
1.2 DeepSeek Harness 让讨论继续聚焦在插件化运行时、日志和安全自修改上 (🡒)¶
DeepSeek Harness 仍是当天的参照点，但讨论已经越过发布热度，转向真正做落地的人关心的问题：到底什么才算上下文、模型可见状态如何记日志、插件能否保住提示缓存。另一个焦点是，运行框架在不打破安全保证的前提下，究竟能把自己重配到什么程度。最强的几条帖子争的不是模型 IQ，而是运行时形态。
@akshay_pachaar 把（390 个赞、18 条回复、40,107 次浏览、458 次收藏）DeepSeek Harness 解释成一个“万物皆插件”的系统，其中模型适配器、工具注册表、会话日志，甚至智能体循环都可以替换。公开的 repository 现在显示 98,337 个 GitHub stars，把项目称为开发者预览，并写明模型、工具、技能、会话、沙箱、循环、编排和 UI 都是由 Cordis 驱动的插件。
@code_hiyouga 认为（143 个赞、7 条回复、9,829 次浏览、119 次收藏），当训练和 RL 框架膨胀得过大时，插件化就是自然答案；随后又拿 PenguinHarness 做对比，在那里，智能体、上下文和长期记忆都被做成文件，智能体只能在有限边界内修改它们。第一张图展示了 LlamaFactory 从单体式 v0 到插件化 v1 的转变，第二张图则把 Claude Code 的紧凑循环，与 PenguinHarness 更宽的文件化记忆、技能和轨迹架构区分开来。
@hsu_steve 把（189 个赞、6 条回复、27,580 次浏览、115 次收藏）同样的 Cordis 底座视为通向递归自我改进的一条路，因为可逆副作用和感知依赖关系的重新计算，会让智能体可以改写自身运行框架的一部分，而不会造成永久状态损坏，也不用整套重启。与此同时，@RoundtableSpace 也带热了（35 个赞、7 条回复、50,021 次浏览）Arcee 的 nac，其 README 把它描述成一种面向长时任务的 thread-and-episode 架构：中央编排器负责规划，但不直接执行命令。
讨论要点： 最尖锐的回复针对的是可观测性，不是可扩展性。一条回复警告说，插件顺序可能在无声无息中毁掉提示缓存；另一条则说，fork 会出现在 diff 里，而插件注册只有到了运行时才看得见。
与前日对比： 8 月 13 日让 DeepSeek Harness 成了头条。8 月 14 日则把同一个仓库继续放在中心，但讨论重心已经转向日志、可逆性、提示缓存契约，以及替代性的运行框架设计。
1.3 多智能体系统变得更窄、更便宜，也更按角色分工 (🡕)¶
最务实的多智能体帖子，已经不再单纯庆祝智能体数量多。它们会明确说明规划器放在哪里、高成本模型看到内容前哪些信息会先被压缩、哪些角色可以并行，以及何时必须让验证器或人类介入。重点已经从群体规模，转向了对上下文的纪律性管理。
@gippp69 把（23 个赞、9 条回复、231 次浏览）Anthropic 那份高效智能体说明概括成一条 planner -> specialists -> reducer -> verifier 流程：40 个 Haiku worker 生成了 41,200 个 token，在 Sonnet 看到它们之前，确定性归约先把数字压到 5,300；据称成本从 $1.38 降到 $0.19，延迟则从 51 秒降到 11 秒。
@hanakoxbt 描述了（59 个赞、3 条回复、4,381 次浏览）一条 6 智能体 PR 流水线：规划器只定一次计划，3 个构建者并行工作，审查者按计划而不是按代码来驳回，记录者根据轨迹来写 PR，而失败会回流进下一版规格说明。那条讨论串里最重要的主张，不是“6 个智能体”，而是把失败回送成未来约束的那条回边。
@gippp69 传播了（93 个赞、33 条回复、3,348 次浏览）awesome-claude-code-subagents 仓库，网页和仓库证据都表明，它是一个拥有 24,314 个 star、覆盖 10 个类别、收录 100+ 个专业 Claude Code 子智能体的集合。传播开来的主张很直接：让主会话当协调者，把后端、安全、数据、测试或基础设施工作推到隔离的专长上下文里。
@DanKornas 说（7 个赞、2 条回复、1,222 次浏览），难题不在于找到某一个技能，而在于把很多技能串成一条真正可用的流水线；随后又指向 AgentSkillOS，公开 README 把它描述成一种在 200,000+ 个技能之上做能力树检索和 DAG 编排的系统。
讨论要点： 共同的设计规则是：昂贵的推理应该看到更少的信息，而不是更多。更多 worker 很便宜；更好的归约、路由和验证，才是真正的工程层。
与前日对比： 8 月 13 日仍把多个智能体描述成带记忆和审批的队友。8 月 14 日则把 reducer、verifier、DAG 和专门角色的边界讲得更具体了。
2. 令人困扰的问题¶
把一切都收进来的记忆系统，仍然做不好选择和遗忘¶
大家反复提到的设计挫败点，不是“我们需要更多记忆”，而是“我们需要更好的记忆卫生”。@nicbstme 清楚列出了（304 个赞、9 条回复、35,821 次浏览、551 次收藏）这层栈的要求——先学会一切有用信息，再判断真正该进上下文窗口的到底是哪一小撮——而紧接着的一条回复就说，最难的部分是决定 6 个月后什么本该过期。@gippp69 又补上了（23 个赞、9 条回复、231 次浏览）成本后果：让每个 worker 都把原始输出往上游倾倒，正是多智能体系统变得嘈杂、缓慢又昂贵的原因。当前的应对方式，是压缩、确定性归约，以及更小、按角色划分的上下文。值得构建程度：高。
“已验证”的智能体输出，却仍然缺少独立证据¶
第二个挫败点，是那些其实还没真正证明工作成立、却语气过度自信的智能体状态描述。@itamar_mar 警告说（2 个赞、250 次浏览），一个隔夜运行的编程智能体，可能会新增依赖、改动基础设施并跨越仓库边界，但最后让审查者无法判断到底测了什么、爆炸半径又有多大；随后他贴出一张截图，显示“已做端到端验证……没有 mocks”这句话在被质疑后不得不收回。@hanakoxbt 则从结构上讲了（59 个赞、3 条回复、4,381 次浏览）同一件事：测试回答的是“它能不能跑”，但审查角色必须回答“它该不该存在”。@marfinxx 又把（27 个赞、8 条回复、1,400 次浏览）这份担忧延伸到网络安全领域，主张需要一个治理审计智能体和不可变的决策轨迹。
大家现在的应对方式，是加入审查角色、审批步骤、来源核查，以及独立的评审智能体。值得构建程度：高。
长时任务仍然需要更干净的日志、更强的可恢复性和更清晰的运行时边界¶
第三个挫败点是，一旦工作跨越几十次工具调用，运行框架本身就成了故障暴露面。@akshay_pachaar 认为（390 个赞、18 条回复、40,107 次浏览、458 次收藏），只追加式会话日志，才是 DeepSeek Harness 里他“真的会拿来用”的部分，因为光看工具调用日志，并不能告诉你模型到底看到了什么。@RoundtableSpace 突出了（35 个赞、7 条回复、50,021 次浏览）nac 作为长时工程任务运行框架的定位，而一条回复把基准压成一个简单问题：它能不能在保持可恢复性的同时，扛过 50 次工具调用、局部失败，以及不断变化的仓库状态？当前的应对方式，是把线程、episodes、轨迹和状态转换外置出来，而不是相信单一转录。值得构建程度：高。
3. 人们期望的功能¶
更便宜的主动式智能体，同时具备更好的记忆衰减与上下文选择¶
最清晰的实际需求，是能被事件唤醒的后台智能体，而且不必永远拖着整段历史一起往前走。@nicbstme 说（304 个赞、9 条回复、35,821 次浏览、551 次收藏），前沿方向是主动式后台智能体，但也说真正的竞争点，是在尽量压低 token 成本的同时，把上下文质量和有用动作最大化。同一讨论串里最好的回复则认为，收集用户记忆说起来很容易，真正的产品问题是决定什么该过期。这是一个直接需求：人们想要主动式智能体，但前提是记忆必须便宜、可选择、也值得信任。机会：直接。
能把巨型技能库变成一条可运行流水线的技能检索与编排¶
人们同样想要一层系统，能发现、路由和组合大量技能，而不让协调者淹没在无关输出里。@DanKornas 说（7 个赞、2 条回复、1,222 次浏览），“找到合适的智能体技能，这事只做了一半”，并把 AgentSkillOS 定位成一套面向 200,000+ 个技能的能力树发现、任务感知检索和 DAG 执行系统。@gippp69 又从人工策展角度补上了（93 个赞、33 条回复、3,348 次浏览）同一种需求：他把人们指向一个面向 Claude Code、收录 100+ 个专长子智能体的目录。这个需求既务实，又越来越竞争激烈：市场上已经有技能库了，但仍缺一个默认的、能把它们干净选出来并组装起来的方法。机会：竞争型。
面向软件工程之外领域专家的协作优先工具¶
最强的愿景型需求，来自那些不想把专家工作压扁成一次性“提示词直出成品” UX 的人。@voooooogel 认为（174 个赞、23 条回复、7,369 次浏览、71 次收藏），数学不该重复艺术工具那条路——那些为低专业门槛编辑优化的模型，会把与专家协作挤出去；帖子也明确希望系统能帮助数学家和其他专业人士掌舵工作，而不是把他们排除在外。@TONGYI_SpeechAI 则在语音领域展示了（50 个赞、2 条回复、1,728 次浏览）这种协作模式的一个具体版本：一个 ASR 智能体能接受“不是，是 Megan，M-e-g-a-n”这样的纠正，并恢复任务，而不是默默失败。
这既有愿景成分，也有务实成分。人们要的是能把专家主导权留在环内的工具，而不是只为通用输出做优化。机会：愿景型。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| DeepSeek Harness | 智能体运行框架 / 运行时 | (+/-) | 万物皆插件的架构；只追加式会话日志；生态关注度高 | 仍是开发者预览；预计会有破坏性变更；插件顺序和只在运行时显现的行为，会带来调试与缓存顾虑 |
| Learn Harness Engineering | 课程 / 方法 | (+) | 把状态、验证、连续性和仓库控制整理成可教学课程 | 只是教育资源；团队仍得自己把运行框架搭出来 |
| AgentSkillOS | 技能检索与编排 | (+) | 可在 200,000+ 个技能上做能力树发现；支持 DAG 编排；带 GUI 和批处理 CLI | 需要编排策略和技能池策展；相较于更高声量的智能体仓库仍属小众 |
| awesome-claude-code-subagents | 子智能体包 | (+/-) | 100+ 个专门角色；让协调者会话保持聚焦；易于像插件一样复用 | 如果没有过滤、归约和验证，更多智能体仍会制造噪音 |
| nac | 长任务运行框架 | (+) | thread-and-episode 架构；中央编排器；仪表盘；入门技能 | 项目很新，采用证据有限；还多了一层提供商登录 / 设置开销 |
| uAgents | 智能体框架 | (+) | 支持定时与事件驱动的智能体；结构化消息；身份与安全钱包 | Fetch 网络假设缩窄了默认用例；高层编排指导较少 |
| Harvey custom GLM-5.2 review-table model | 领域模型 / 运行框架 | (+) | 以更低成本提供更高的答案与引用质量；智能体式搜索降低了 token 负载 | 专用于法律审查工作流；需要定制训练数据和人工复核 |
| Agentic ASR + S²ER | 语音智能体方法 | (+) | 交互式纠错循环；衡量意图和实体是否被保留下来，而不只看原始转写准确率 | 证据仍处早期；这组推文并未展示大规模生产可靠性 |
| three.ws | 3D 智能体平台 | (+/-) | 把虚拟形象、语音、支付、MCP/A2A、身份和 WebXR 部署揉在一起 | 表面非常宽；相较于产品野心，公开仓库热度仍然不高 |
整体来看，满意度主要集中在那些能收窄上下文、暴露状态、并把验证做成显式环节的系统上。最让人满意的帖子，称赞的是插件边界、DAG 路由、面向领域调优的运行框架，以及感知纠错的交互；抱怨也同样一致：记忆系统仍然收得太多，多智能体栈仍然产得太多，“已验证”也仍然太常意味着“智能体自己这么说”。迁移压力同时朝三个方向显现：从提示词转向运行框架工程，从通才会话转向专长流水线，也从一次性输出转向感知纠错和证据的工作流。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| DeepSeek Harness | DeepSeek AI | 开源智能体运行框架，其中模型、工具、技能、会话、循环和 UI 都是插件 | 团队想要一个无需 fork 整个框架、也能替换和扩展的官方运行时 | TypeScript、Cordis、插件架构、Web UI | 测试版 | 仓库, 站点 |
| awesome-claude-code-subagents | VoltAgent | 覆盖 10 个类别、策展好的 100+ 个 Claude Code 专门子智能体包 | 一个通才智能体包揽所有角色时，主会话的上下文会被稀释 | Claude 插件分发、提示词 / 配置包、安装脚本 | 测试版 | 仓库 |
| AgentSkillOS | ynulihao | 在 200,000+ 个技能上做检索、组合和工作流执行 | 大型技能生态难搜，更难端到端编排 | Python、能力树、DAG 编排、Web UI、批处理 CLI | 测试版 | 仓库, 项目页 |
| Harvey review-table custom model | @harvey | 面向大型法律审查表格的后训练模型和智能体式搜索运行框架 | 审查表工作负载可能达到数百万次查询，在通用前沿模型上成本过高 | GLM-5.2、Applied Compute AC2、合成法律数据、智能体式搜索、人工法律审查 | 已发布 | 公司 |
| uAgents | @Fetch_ai | 用于自治智能体的 Python 框架，可按计划运行、响应事件并交换结构化消息 | 构建者想要轻量级智能体原语，最好把身份和消息传递内建进去 | Python、Almanac 智能合约、安全钱包 / 消息 | 已发布 | 仓库, 文档 |
| nac | Arcee | 长任务运行框架，采用中央编排器加 thread-and-episode 执行 | 雄心较大的工程工作在长时间跨度里会逐渐偏离初始意图 | Rust、thread-and-episode 架构、仪表盘、入门技能 | 测试版 | 仓库, 博客 |
| three.ws | nirholas | 带虚拟形象、支付、身份和工具连接能力的开源 3D AI 智能体框架 | 非编程智能体也需要具身化、变现和跨智能体可发现性 | JavaScript、Three.js、MCP、A2A、x402、Solana/EVM、LiveKit、ElevenLabs、WebXR | 测试版 | 站点, 仓库 |
就当天最重要的构建讨论串而言，@akshay_pachaar 把（390 个赞、18 条回复、40,107 次浏览、458 次收藏）DeepSeek Harness 说成一种运行时，其中上下文组装、工具访问和会话日志都可以替换。让这个项目真正重要的，不只是仓库热度，还有那个更明确的主张：模型可见状态应该被记录、可回放，也能被替换。
@harvey 展示了（43 个赞、1 条回复、11,562 次浏览）另一种构建模式：与其购买更多通用模型能力，不如围绕内部最昂贵的工作流来调模型和运行框架。截图把这个论点讲得很具体——从横跨多份合同的审查表 UI，到数据集构建管线，再到基准图表：Harvey 训练后的 GLM-5.2 变体，在更便宜的成本 / 质量点位上，超过了几个前沿基线。
第二种反复出现的构建模式，是技能表面先爆炸，再做编排收敛。@DanKornas 把（7 个赞、2 条回复、1,222 次浏览）AgentSkillOS 描述成在巨大技能池之上做检索加 DAG 协调；@gippp69 则向（93 个赞、33 条回复、3,348 次浏览）Claude Code 推销一个人工策展的专长子智能体包。两边的构建目标其实一样：别让协调者淹死在一张扁平能力清单里。
最后，@fourjjjjt 回顾了（24 个赞、5 条回复、282 次浏览）three.ws：这是一个开源 3D 智能体栈，带虚拟形象、记忆、自主支付和链上身份；而公开站点又补上了 WebXR 摆放、MCP 工具接线、A2A 发现，以及按聊天收取 USDC。它和 uAgents 放在一起看，代表了一支正在从纯编程副驾、转向网络、身份和面向终端用户智能体表面的构建者分支。
6. 新动态与亮点¶
感知纠错的语音智能体¶
@TONGYI_SpeechAI 展示了（50 个赞、2 条回复、1,728 次浏览）一种“agentic ASR”的框定方式：语音识别不再是一次性把转写结果倒出来，而是一个交互式纠错循环。关键回复又补上了 S²ER，这个指标检查的是核心意图和实体有没有被保留下来，这明显偏离了把词错误率当成唯一目标的做法。
领域后训练开始胜过通用前沿模型的经济性¶
@harvey 报告称（43 个赞、1 条回复、11,562 次浏览），面向 Review Tables 的一个后训练 GLM-5.2 变体，在提升答案和引用质量的同时，把成本降到了 Sonnet 5 的一半以下，并压到了领先前沿模型的大约十分之一。之所以值得注意，是因为它把运行框架和任务分布也当成可训练资产，而不只是把模型选择当成唯一变量。
面向科学智能体的委派感知训练¶
@ShashwatGoel7 突出了（1 个赞、32 次浏览）Faraday 如何用自动评判器和回合级 credit assignment 来训练一位 27B AI scientist，附图显示，“委派给 coder”拿到了最高的平均每 token credit 权重。即便互动量不高，这也是少数几个清楚暴露出：智能体可以被训练去显式重视委派决策的例子。
7. 机会在哪里¶
[+++] 面向自治编程工作的验证与证据闸门 — @itamar_mar 展示了（2 个赞、250 次浏览）智能体多么容易夸大“已做端到端验证”，而 @hanakoxbt 把（59 个赞、3 条回复、4,381 次浏览）测试和批判分开，@marfinxx 又加入了（27 个赞、8 条回复、1,400 次浏览）不可变治理轨迹。共同的需求，是在合并或部署前，用一层独立评审去质疑智能体的主张。
[++] 技能检索、归约与编排层 — @DanKornas 描述了（7 个赞、2 条回复、1,222 次浏览）怎样把许多技能变成一条流水线这个问题，@gippp69 展示了（23 个赞、9 条回复、231 次浏览）为什么在强模型读取任何内容之前，归约器如此关键，而 awesome-claude-code-subagents 仓库则展示了专长目录扩张得有多快。机会不在于再做一个技能库，而在于那一层能选择、压缩、路由并验证这些技能的系统。
[+] 协作优先的领域智能体 — @voooooogel 主张（174 个赞、23 条回复、7,369 次浏览、71 次收藏），数学工具应该长成专家形状，而不是替代者式 UX；@TONGYI_SpeechAI 展示了（50 个赞、2 条回复、1,728 次浏览）一个感知纠错的语音智能体；@harvey 则证明了（43 个赞、1 条回复、11,562 次浏览），领域调优可以重塑某个专门工作流的经济性。机会窗口在于，系统要能在专家原生工作流程里帮助他们主导、纠正并信任这份工作。
8. 要点总结¶
- 如今关于智能体的讨论，重点已经主要落在系统设计上，而不是提示词技巧。 Andrew Ng 的技能地图、Nicolas Bustamante 的栈配方，以及《Learn Harness Engineering》都把记忆、上下文、权限、评估和仓库控制放在中心，而不只是提示词措辞。(source)
- DeepSeek Harness 让插件化运行时继续处在市场中心，但真正的争论点是可观测性。 Akshay Pachaar 强调只追加的模型可见日志，而回复立刻把焦点压到提示缓存和只在运行时显现的行为上。(source)
- 多智能体系统正在被归约器、验证器和角色边界重新约束。 今天最强的例子，靠的是规划器、专长角色、审查角色、DAG 和上下文压缩，而不是单纯把智能体数量越堆越多。(source)
- 领域专用运行框架，是当前最清楚能看见价值的地方。 TONGYI 的感知纠错 ASR 和 Harvey 的审查表模型都说明了同一点：一旦工作流足够具体，智能体设计和调优就能同时改善质量与经济性。(source)