Twitter AI 智能体 - 2026-07-15¶
1. 人们在讨论什么¶
1.1 技能工程正在沉淀为可复用的运行框架设计 (🡕)¶
信号最强的一簇工程讨论认为，智能体的质量取决于包在模型外面的系统，而不是某个巧妙的一次性提示词。至少有 5 条保留下来的内容，从不同角度推进了同一个框架：把 skills 当成结构化机器，把 harnesses 当成可检查的控制平面，把任务世界当成可以组合、审计和修补的对象。这是 7 月 14 日“循环 + 评估”讨论的直接延续，只不过重点已经从词汇，转向可复用的实现模式。
@hnshah 认为，“AI 技能现在还总是被写成提示词”，并把读者引向 Paul Bakaus 的《Skill engineering and the case against one-shot AI design》；这篇文章把可复用技能定义成结构化、可由人类引导的系统，而不是一次性自动化（126 点赞、6 回复、30,637 浏览量、318 收藏）。@ShenSeanChen 开源了 Waku Agent：README 说它的核心循环大约只有 95 行 Python，同时带有 SQLite 记忆、确定性测试，以及会在仪表盘里显式展示的 LLM-as-judge 评估，而不是把这些东西藏在框架后面（69 点赞、7 回复、3,691 浏览量、107 收藏）。@TheodoreGalanos 又通过 Task Worlds / Meta-Harness把同一个论点往前推了一步：智能体任务不该被当成泛化的提示词，而该被视为拥有具名证据、权限和修复循环的“世界”（16 点赞、1 回复、6,946 浏览量、26 收藏）。
@hugobowne 预告了 一场直播工作坊：它从一次单独的模型调用开始，然后再把运行框架一层层搭起来——工具 schema、记忆、安全护栏、trace、eval，以及失败分析（4 点赞、2 回复、326 浏览量）。
讨论要点： 回复一直把这个主题拉回失效模式本身。Hiten Shah 那条帖子下，有回复说 Claude Code 插件之所以老出问题，是因为它们“是按提示词写的，不是真正带 fallback 的系统”；而 @gmickel 写道，团队仍然需要学会“智能体式思维”，把 skills 当成原语，而不是紧箍咒；Flow-Next 的文档则用持久规格、对抗式审查循环，以及严肃交接用的“凭据”，把这个思路落到了实处（3 点赞、681 浏览量、3 收藏）。
与前日对比： 7 月 14 日的重点还在循环类型、评估器闸门和受治理的 skills。到了 7 月 15 日，讨论又往下一层走：大家开始关心这些循环和 skills 应该怎么编码，才能扛住模型、运行框架和上下文的变化。
1.2 循环工程开始变成课程、认证和检查清单 (🡕)¶
第 2 簇讨论显示，循环工程正在从构建者之间的“口口相传”，转向正式训练。证据并不只是几句口号：帖子里已经开始引用官方课程目录、认证备考内容，以及验证器层、停止规则、进度记忆文件等明确的循环组件。
@RoundtableSpace 提到 了一门被描述为 Anthropic 官方的循环工程课程（28 点赞、12 回复、22,052 浏览量）；与此同时，@AlexRiad84837 整理了 一份 13 门课程的 Claude 清单，其中包括 Claude 101 和 Introduction to Agent Skills；后者明确讲了 skills 与 CLAUDE.md、hooks 和 subagents 的区别（16 点赞、7 回复、131 浏览量）。@HeyAnjula 分享了 一份为期 6 周的 Claude Certified Architect - Foundations 考试准备计划，里面包含 multi-tool agent、团队工作流和多智能体研究管线练习（8 点赞、2 回复、226 浏览量）。@aiedge_ 概述了 一套 6 部分循环结构：触发器、执行层、验证器、停止规则、记忆和 skills（8 点赞、1,067 浏览量）。
讨论要点： 这一簇里最尖锐的回复，来自那条课程推文下方：停止条件“是我最浪费 token 和时间的地方”，但官方材料往往一带而过。这个批评和那张结构图是对得上的——后者在失败终止、重试上限和 token 预算上花的篇幅，比在提示词本身上还多。
与前日对比： 前一天，评估和治理还是运营必需品；而今天，同样的内容已经以可教学材料和认证体系的形式出现了。这说明循环工程正在变成一个入门界面，而不只是高级实践者的习惯。
1.3 多智能体产品化开始落在真实工作界面上，而不只是聊天窗口 (🡕)¶
当天最清晰的构建活动，来自那些给智能体提供持久工作场所的人：把它放进笔记仓库、放进基于角色的团队花名册，或者通过明确的 MCP 工具界面来运作。相比昨天那些 issue-tracker 和生命周期 demo，今天的新材料更可安装，也更贴近具体工作流。
@israfill 展示了 Claudian：它把 Claude Code 接进 Obsidian，让智能体能改写笔记、关联相关文件，并直接原地编辑 markdown（16 点赞、9 回复、1,078 浏览量）。Claudian 仓库写明，它支持在 vault 内做 inline edit、plan mode、slash commands、skills 和 MCP servers。@sairahul1 重点提到 Agency Agents：这是一个拥有 131,820 星、覆盖工程、设计、营销、产品、测试和支持的专门化智能体花名册，并主张“专门角色 + 循环”比一个通才提示词更可扩展（16 点赞、13 回复、2,374 浏览量、21 收藏）。@TheCodeMan__ 分享了 一个 AI in .NET Starter Kit 示例：它用 MCP server 运行压测、比较端点、识别 thread-pool starvation，并通过智能体工具调用生成报告（8 点赞、3 回复、246 浏览量）。
讨论要点： 这一簇回复里，人们问的是智能体集群的成本，以及角色之间的交接边界。一位回复者问，一个 50 多智能体的花名册在 200 美元套餐下是否负担得起；另一位则追问，团队怎么避免 3 号智能体把 1 号智能体已经拍板的事又做一遍。这些都是很具体的编排问题，而不是对方向本身的反对。
与前日对比： 7 月 14 日的构建者还主要在描述循环模式和治理层。7 月 15 日则补进了更具体的打包形式：可安装的 vault 助手、可下载的 starter kit，以及预先编排好的智能体团队。
2. 令人困扰的问题¶
提示词式 skills 在模型、运行框架或上下文一变时还是会坏¶
当天最响的抱怨，并不是孤立地批评模型质量，而是在批评脆弱的运行方式。@hnshah 认为，那些像提示词一样写出来的 skills，一旦模型、运行框架或上下文发生变化就会“塌掉”；而一条回复则把这种失效说得更具体：Claude Code 插件之所以在更新后不断出问题，就是因为作者写它们时没有准备 fallback（126 点赞、6 回复、30,637 浏览量、318 收藏）。@gmickel 补充说，就算 skill 库本身很强，如果用户没学会把它们当成可组合原语来用，它们照样会失效（3 点赞、681 浏览量、3 收藏）。严重程度：高，因为这个问题同时出现在产品使用和内部赋能两个层面。
停止条件和交接，依然是自治最贵的部分¶
大多数关于循环的讨论，底层真正的挫败感并不是“怎么把循环启动起来？”，而是“我怎么知道它什么时候算结束，以及怎么不让多个智能体互相踩来踩去？” 那条 Anthropic 课程推文下的回复说，退出条件是大家最容易浪费 token 和时间的地方；而 @aiedge_ 明确写出了 成功 / 失败停止规则、重试上限和 token 预算（8 点赞、1,067 浏览量）。@sairahul1 的 Agency Agents 帖子下的回复，也提出了同样的担心：token 烧得快，以及角色之间交接后容易发生漂移（16 点赞、13 回复、2,374 浏览量、21 收藏）。严重程度：高；当前可见的通用权宜方案，是补验证器、写进度文件，并且把角色边界收得更窄。
创意型智能体仍然会误解用户意图和框架语义¶
最尖锐的一手失败报告来自 @luciascarlet。她描述了一个 Figma shader 任务：内置智能体把“做一个旋转手柄”的请求理解成把旋转范围放大到 3600 度，还把位置手柄映射成根本没法用的相对坐标（12 点赞、4 回复、715 浏览量）。这比“输出看起来不太好”更深一层——智能体误解的既是用户意图，也是它所在界面的操作模型。
严重程度：中高，尤其对设计工作流来说，因为这种失败是语义层面的，而且排查成本很高；从数据里能看到的唯一应对方式，仍然只有手工修正和反复重试。
生产级安全护栏，依然被视为缺失的基础设施¶
@AiCamila_ 认为，大多数生产级智能体失败，并不是因为模型能力不够，而是因为缺少安全护栏（12 点赞、3 回复、188 浏览量）。配图把这个缺口拆成了 policy / governance、输入校验、工具控制、输出检查，以及监控 / 回滚几层。
严重程度：中。今天围绕这个话题的讨论量不如循环线程大，但很值得构建，因为提到的控制点都直接对应真实部署里的失败面。
3. 人们期望的功能¶
能扛住上下文和模型变化的技能¶
Hiten Shah 的框架、他引用的 Paul Bakaus 文章，以及 Flow-Next 的指导说明，共同指向一个很直接的需求：技能应该像耐用的运行模块，而不是脆弱的提示词产物。人们想要的是那种即便模型变了、代码库变了、周围运行框架也演化了，依然能继续工作的可复用指令。今天已经能看到一些局部答案，比如 Introduction to Agent Skills、Flow-Next，以及 Waku 这一类运行框架，但这个需求依然既现实又紧迫。机会：直接。
面向长时循环的验证器和停止规则脚手架¶
围绕课程的那条回复、aiedge 的循环结构图，以及 agency 花名册下面关于交接的提问，实际上都在指向同一个缺口：团队想要有一套标准方式来表达“做完了”“重试”“放弃”和“求助”。这不是一个理想化愿望；当这些规则只存在于暗知识里时，人们已经在损失时间和开销。现有的局部答案，是自定义进度文件、LLM-as-judge 检查，以及硬性的迭代上限。机会：直接。
能直接作用于真实知识库的智能体原生工作空间¶
Claudian 那条帖子，展示了一个非常具体的愿望：别再把笔记来回复制到聊天窗口里，而是让智能体直接在 markdown、链接和 vault 结构上工作。这个需求是务实的，而不是情绪性的：人们想要的是让自己的笔记、规格和上下文，成为可编辑的工作记忆，而不是被粘贴进来的附件。Claudian 已经部分满足了这个需求，但配置摩擦、CLI 路径问题和持续的模型使用成本仍然存在。机会：竞争激烈。
具备可预测成本、且漂移很低的多智能体交接¶
Agency Agents 帖子下的回复，把缺失部分说得很明白：角色之间到底怎么交接工作，才不会把已经做过的决策再做一遍？整个 swarm 跑起来到底有多贵？WebSwarm 通过递归委派和证据聚合，给出了一个面向研究的答案，但生产层的问题更广：团队想要的是既能保住上下文、能追踪成本，又不让角色越跑越偏的编排系统。机会：直接，而且很可能会和编排框架及平台供应商形成正面竞争。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Waku Agent | 本地优先智能体运行框架 | (+) | 可读的 Python 循环、SQLite 记忆、确定性和裁判式 eval、本地仪表盘 | 仍属早期项目，目前采用证据有限 |
| Flow-Next | 智能体工程工作流 | (+/-) | 持久规格、对抗式审查循环、重新锚定的 worker、交接凭据 | 仍要求团队学习一种新的运行方式 |
| Claudian | Obsidian 工作区插件 | (+) | 直接读写 vault、inline edit、plan mode、skills、MCP 支持 | 配置摩擦、CLI 路径问题，以及持续的模型使用成本 |
| Agency Agents | 角色专长智能体包 | (+/-) | 大量专门智能体角色，可安装到多种编程智能体工具里 | 回复质疑 swarm 成本和角色间漂移 |
| AI in .NET Starter Kit | MCP 示例 / 开发工具链 | (+) | 具体的 MCP 用例、10 个工具、性能分析工作流、教学清晰 | 明确定位成教学材料，而不是生产就绪产品 |
| WebSwarm | 递归式研究框架 | (+) | 深搜 / 广搜模式、递归委派、证据聚合 | 可运行代码仍待完整发布 |
| Figma 内置智能体 | 设计智能体 | (-) | 能在设计工具里直接处理 shader 编辑请求 | 首次使用就误判意图、误解界面语义，而且体感较慢 |
正向评价明显集中在那些让智能体行为可检查的方法上：可读循环、具名技能、明确的停止规则、持久规格，以及通过 MCP 暴露出来的工具界面。只要任务要求智能体跨开放式交接保留细腻的人类意图，或者需要理解视觉编辑语义，满意度就会下降；这也是为什么验证器层和直接上下文工作空间会反复出现。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Waku Agent | @ShenSeanChen | 一个本地优先的个人助手，用可读代码显式暴露运行框架、循环、记忆、trace 和 eval | 给构建者一份可检查的参考实现，而不是一个黑盒助手 | Python、SQLite、本地仪表盘、Telegram / 语音集成、确定性 + LLM-as-judge eval | Shipped | GitHub |
| Claudian | YishenTu / @israfill | 把 Claude Code 和其他编程智能体直接嵌入 Obsidian vault | 消除笔记和聊天之间的复制粘贴，让智能体能原地编辑持久知识库 | TypeScript、Obsidian 插件、Claude Code / Codex / Opencode / Pi、MCP | Shipped | GitHub |
| Agency Agents | msitarzewski | 一个可安装的大型专门智能体花名册，覆盖工程、设计、营销、产品和支持 | 用按角色委派取代单个通才智能体模式 | Markdown 智能体定义、安装脚本、原生桌面应用、多工具集成 | Shipped | GitHub、应用 |
| AI in .NET Starter Kit | @TheCodeMan__ | 一个教学用 .NET starter，展示语义搜索、RAG 和用于 API 性能分析的 MCP server | 用真实的 MCP 工作流替代玩具计算器 demo | .NET、ASP.NET Core、Blazor、自定义压测引擎、10 个 MCP 工具 | Shipped | 站点 |
| Aster | @chiziaruhoma | 一个即将发布的 Rust 开源代码审查运行框架 | 把代码审查当成上下文管理和作用域控制问题来处理 | Rust | Alpha | 推文 |
| WebSwarm | songxiaoshuai et al. | 一套带自适应深搜 / 广搜模式的递归式多智能体网页搜索系统 | 通过动态委派子问题并聚合证据，处理长周期研究任务 | 递归委派树、搜索模式、研究综合 | RFC | arXiv、GitHub |
Waku Agent 是当天核心设计哲学最清晰的实体化例子。这个 repo 不只是一个 demo app；它把自己定位成一份可读蓝图，教人怎么做运行框架、循环、记忆和 eval，这和当天反复出现的诉求高度一致：人们要的是可检查性，而不是“神奇提示词”。Claudian 解决的则是另一个相邻痛点：它给智能体一个持久工作空间，所以记忆和编辑都发生在用户本来就思考的那套笔记系统里。
Agency Agents 和 WebSwarm 则展示了同一趋势的规模化一面。前者把专门角色打包成可安装的队友，后者则把递归委派打包成一套面向深搜和广搜的研究架构。两者回应的，都是信息流里反复出现的同一个直觉：如果工作需要拆解、审查和收集证据，那么一个智能体只跑一遍根本不够。
@TheCodeMan__ 展示了 这一组里最具体的 MCP 例子：它不是把智能体连到一个泛化助手壳子上，而是直接连到真实的 API 性能工具链（8 点赞、3 回复、246 浏览量）。
反复出现的构建模式很一致：给智能体直接访问持久上下文的能力，把它的角色收窄，加上一层验证或审查，并把工具边界明确写出来。触发这些模式的痛点也同样一致：黑盒行为、交接时的上下文丢失，以及在人类工作界面和智能体界面之间来回复制粘贴太多。
6. 新动态与亮点¶
面向网页研究的递归委派，有了一个具名架构¶
@zarqXBT 重点提到 WebSwarm：它把“生成子智能体、让它们深挖、最后再合并证据”这件事，变成了一种具体的递归编排模式（9 点赞、3 回复、130 浏览量、6 收藏）。所链接论文写明了 deep、wide、atom 和 entity-collect 等自适应搜索模式，以及一种自底向上的证据聚合方式，而不是预先规划好的固定拆解。它之所以重要，是因为当天其他关于多智能体的讨论，大多还停留在产品打包或角色花名册层面；而这篇论文，是当天最清晰地把研究循环本身形式化出来的公开产物。
代币化的智能体所有权变得更具体了，但证据仍然很薄¶
当天那簇非工程类讨论，把智能体描述成经济行为体和链上资产，而不是开发者工具。@WorldOfMercek 梳理了 一个去中心化 AI 生态图，覆盖智能体需求、路由、推理、模型、GPU 供给和资本形成（111 点赞、40 回复、2,485 浏览量、20 收藏）；与此同时，@mickeymantled 认为，Brainfart 的 “mind pieces” 让智能体本身，而不只是外层 token，成为可持有资产（182 点赞、13 回复、20,248 浏览量、6 引用）。
这之所以值得关注，不是因为“智能体 token”这件事本身新鲜，而是因为发帖者现在已经开始提供 UI 级和类别级的解释，来说明所有权、支付和市场结构。最有力的修正来自回复区：有人在那张生态图下直接说，除非这些智能体能持续创造真实需求，否则整套叙事大多还是 hype——而这恰恰就是这一簇当前最没解决的证据缺口。
7. 机会在哪里¶
[+++] 耐用的技能与运行框架基础设施 —— 第 1、2、4、5 节里最强的证据都在说明，人们已经不再想要“更好的提示词”；他们想要的是可复用的技能、可检查的循环、可见的评估，以及能扛住模型和上下文变化的运行框架。Waku、Flow-Next、Bakaus / Hiten 的框架，以及那篇 meta-harness 文章，都在直接支撑这一点。
[++] 面向长时循环的验证器、停止规则和交接控制 —— Anthropic 课程和 agency 花名册那两条帖子下的回复，点出了同样的瓶颈：退出条件不清、token 浪费，以及角色漂移。这是一个很强的运营机会，因为痛点具体且反复出现，但它很可能会和编排供应商及模型平台特性正面竞争。
[++] 面向持久上下文的智能体原生工作空间 —— Claudian 和 .NET starter kit 都说明，人们想要的是智能体待在工作本来就发生的地方：vault、repo、API、仪表盘，以及结构化项目记忆里。这个机会很实在，因为现有方案依然伴随着配置摩擦、提供商成本，或者更偏教学材料而不是成熟产品。
[+] 面向智能体经济的证明和遥测层 —— 链上那簇讨论显示，人们确实对“可持有”或“可货币化”的智能体基础设施感兴趣，但回复也在追问，这些东西到底能不能持续创造真实需求。这就形成了一个正在出现的机会：做出能证明使用量、归因和价值累积的系统，而不只是再画一层叙事地图。
8. 要点总结¶
- 当天最核心的技术信息是：skills 应该像系统，而不是像提示词。 Hiten Shah 的帖子、那篇技能工程文章、Waku Agent 以及 meta-harness 文章，都收敛到同一个观点：耐用的脚手架，比一次性指令更重要。(来源)
- 循环工程正在变成正式课程。 看起来像官方的课程目录、认证备考内容，以及可视化的循环检查清单，都说明构建者现在已经期待用结构化训练来学习 skills、MCP、验证和停止规则。(来源)
- 最务实的产品化工作，发生在智能体接触真实工作界面的地方。 Obsidian vault 集成、MCP 驱动的开发者工具，以及可读的本地运行框架，都比通用助手 demo 更具体，因为它们直接作用于持久上下文和真实工具。(来源)
- 最难解决的问题，依然是退出条件、交接，以及对意图的忠实理解。 回复区抱怨的是 token 浪费和角色漂移，而 Figma shader 那条失败报告则说明，智能体第一次接触任务时，仍然会同时误解用户意图和界面语义。(来源)
- 一条并行增长的链上智能体叙事正在形成，但证据缺口也非常明显。 发帖者已经给出了生态图、所有权 UI 和市场主张，但那一簇里最强的回复，立刻就在问：这些智能体到底有没有创造真实需求？(来源)