Twitter AI Agent - 2026-06-08¶
1. 人们在讨论什么¶
1.1 闭环与运行框架工程成了可靠编码智能体的工作语言 🡕¶
6 月 8 日最明显的转向，是大家不再泛泛讨论提示词，而开始明确讨论闭环、运行框架和验证设计。5 条留存条目支撑了这一主题，而且它们从不同角度描述的是同一套技术栈：长时间规划阶段、ADR、评估、轨迹，以及可复用的闭环结构。
@KingBootoshi 表示（112 次点赞、11 条回复、6,578 次浏览、179 次收藏），GPT-5.5 和 Opus 4.8 让他过去那套高度依赖子智能体的工作流过时了。现在他把大部分时间花在意图对齐上，让一个 Codex 智能体读取原始代码和 ADR，然后让它写总 PRD、运行 goal mode、亲自试用应用，并重新跑 E2E 测试；回复里还补充说，他仍会把 Opus 或 Claude Code 留给前端工作，而把 Codex 用在关键后端改动上。
@eng_khairallah1 分享（50 次点赞、19 条回复、5,859 次浏览、70 次收藏）了 《Learn Harness Engineering》，称其为一门免费大师课。仓库说明这门课程提供 12 节讲座、6 个项目、一个 harness-creator 技能，以及 14 种语言翻译；附图则把 OpenAI、Anthropic 和 ThoughtWorks 的运行框架思路浓缩成了一份便于操作者理解的总结。
@adxtyahq 补充（64 次点赞、3 条回复、1,223 次浏览、69 次收藏）了一套资源栈，链接到了 Huyen Chip、OpenAI 的评估指南、Anthropic 的上下文工程文章，以及 Claude cookbook 材料。这张图之所以重要，是因为它把社区心中的工作闭环展示成了一套系统设计：模型、工具使用、环境、记忆、安全护栏和评估，而不是另一条提示词技巧。
@IntuitMachine 总结（33 次点赞、1 条回复、2,778 次浏览、33 次收藏）称，新阶梯依次是上下文工程、运行框架工程、意图工程，再到闭环工程，并引用了 @steipete 的推文：工程师应该设计的是那些去提示智能体的闭环。@Vtrivedy10 认为（32 次点赞、3 条回复、2,751 次浏览、16 次收藏），长时程改进本质上是一个数据挖掘问题，建立在轨迹、评估创建和数据整理之上。
讨论要点： 有价值的细节已经不是“把提示词写得更好”，而是“把闭环设计好，把智能体约束在明确边界内，一旦偏航就去挖轨迹”。
与前日对比： 6 月 7 日已经出现了公开的运行框架课程和一套默认改进配方。6 月 8 日则新增了明确的操作者手册、“闭环工程”这套术语，以及对 ADR、轨迹和基于评估迭代的更强强调。
1.2 模型路由和本地 swarm 成了务实的成本与性能策略 🡕¶
第二个讨论簇把模型选择看成路由问题，而不是忠诚度竞赛。4 条留存条目支撑了这一主题，而且全部聚焦在团队如何在接近生产的闭环里，实际混用前沿模型、便宜模型、本地 worker，以及审批模式。
@levie 表示（118 次点赞、31 条回复、30,808 次浏览、93 次收藏），市场正在分化：高端工作用前沿智能，高吞吐工作用便宜得多的模型。被引用的 @brian_armstrong 帖子 让这一判断更尖锐——他估计 80% 的工作负载会转向便宜 99% 的模型；而回复则补充说，路由只有在指令和任务结构也跟着模型调整时才有效。
@KimiDevs 宣布（346 次点赞、25 条回复、11,343 次浏览、67 次收藏）Kimi Code 的一次重大升级：一行安装、视频输入、插件钩子、ACP 编辑器支持，以及自定义工作流。GitHub README 证实了 MCP 配置、内置 coder、explore 和 plan subagent，以及 marketplace 安装；而一条回复给出了当天最具体的提醒：这个智能体在一个自己解决不了的提示上陷入了循环。
@DeRonin_ 表示（47 次点赞、14 条回复、1,355 次浏览、14 次收藏），Kimi Work 改变了单人智能体运营的经济模型，因为他可以把大约 90% 的工作路由到 Kimi 2.6，把 Opus 或 GPT-5 留给高风险的架构与安全任务，再把收尾工作交给本地模型。他是在回应 @Kimi_Moonshot 对一款桌面智能体的官方公告：这款产品支持最多 300 个并行 worker、浏览器使用，以及持续运行的记忆日记。
@reach_vb 建议（53 次点赞、13 条回复、1,992 次浏览、13 次收藏），对于长时间任务，应默认把 Codex 切到 “Approve for me”。公开的权限模式文档 解释了这种模式为什么能在编码智能体里引发共鸣：acceptEdits 和其他更宽松的模式能减少提示疲劳，同时保留受保护路径和升级点的防线。
讨论要点： 信息流里的成本讨论已经不再是“哪个模型赢了”，而是“哪个模型负责规划、哪个负责执行、它能在无人看管下跑多久，以及人还会在什么地方介入”。
与前日对比： 6 月 7 日已经有成本优化配方和少量 planner-worker 讨论。6 月 8 日把它扩展成更明确的“前沿模型 vs. 便宜模型”路由论点，并推出了本地 swarm 产品。
1.3 技能和操作层开始进入主流产品界面 🡕¶
第三个讨论簇关注的是，如何把上下文、能力和控制封装进可复用界面，而不是再造一个聊天壳子。5 条留存条目支撑了这一主题，覆盖 Slack、部署 marketplace、工作流模板、声明式运行时，以及 IDE 原生技能。
@_avichawla 认为（16 次点赞、5 条回复、1,079 次浏览、16 次收藏），只活在终端里的编码智能体，到了仓库边界就停住了，看不到真正解释事故的生产告警、PR 历史和 Slack 决策。公开的 CodeRabbit Agent for Slack 文档 证实，这个产品就是为了调查代码库、生成编码计划、发起 PR，并在仓库、工单、监控和文档之间保留一个有作用域的知识库。
@gmi_cloud 发布（59 次点赞、27 条回复、50 次引用、7,527 次浏览）GMI Agent Box，称其是“面向可投入生产的 AI 智能体的一整套基础设施栈”。公开的概览和产品页 展示了同样的封装动作：可直接使用的智能体、面向开发者的部署与上架流程、算力与模型访问，以及 marketplace 信任徽章。
@tonbistudio 分享（24 次点赞、1 条回复、1,750 次浏览、29 次收藏）了开源的 Hermes multi-agent workflow，其 README 给出了一条具体路径：从接单和去重，到并行研究、路由、一个人工闸门，再到最终交付。@TheTuringPost 把（11 次点赞、3 条回复、1,064 次浏览、17 次收藏）OpenProse 描述为一层“逻辑英语”，用于编写可复用的智能体程序；该项目自己的文档则表示，Markdown 契约声明的是目标世界状态，而 Reactor 会在留下持久收据的同时负责协调它。
@luka_bernardi 表示（50 次点赞、4 条回复、2,166 次浏览、15 次收藏），Xcode 现在内置了面向 SwiftUI 的智能体技能，并且可以导出给任何智能体使用。Apple 当天的新闻稿和 Paul Hudson 的 SwiftUI Agent Skill 都指向同一个方向：技能正变成可移植、可安装的最佳实践包，而不是一次性的提示词经验。
讨论要点： 这些产品的共同点，是对结构化上下文的封装——技能、作用域、契约和部署元数据——而不是又一个通用智能体演示。
与前日对比： 6 月 7 日围绕技能的讨论还主要集中在独立的 manager 和 debugger。6 月 8 日则把技能推进了 Xcode、Slack、工作流模板和部署栈。
2. 令人困扰的问题¶
审批疲劳和人工盯盘仍然限制着智能体吞吐¶
严重程度：高。@KingBootoshi 表示（112 次点赞、11 条回复、6,578 次浏览、179 次收藏），讨论阶段是关键工作中最重要的部分，而一次好的运行仍可能耗费 1 到 2 小时，所以一旦对齐出错，代价就很高。@reach_vb 建议（53 次点赞、13 条回复、1,992 次浏览、13 次收藏）启用 “Approve for me”，因为每次工具调用都手动批准会打断心流；公开的权限模式文档 也说明了原因：更宽松的模式本来就是为减少提示疲劳而设计，同时保留受保护路径和升级机制。大家现在的应对方式，是把计划前置、写好 ADR，并只把权限放宽到足以让长时任务继续跑下去。这值得构建，因为人们要的不是鲁莽的自治，而是更好的中间控制层。
上下文和记忆缺口仍会打断长时程连续性¶
严重程度：高。@_avichawla 认为（16 次点赞、5 条回复、1,079 次浏览、16 次收藏），一个只活在终端里的编码智能体，看不到生产告警、引发它的 PR，也看不到团队曾在 Slack 里决定不要碰重试逻辑的那条讨论串。@Vtrivedy10 表示（32 次点赞、3 条回复、2,751 次浏览、16 次收藏），持续学习和长时程改进，说到底是一个建立在轨迹、评估创建和数据整理之上的数据挖掘问题；而 @Kimi_Moonshot 为 Kimi Work 发布的公告，则把“持续运行的日记”当成核心功能，而不是锦上添花。现在的权宜方案包括 ADR、Slack 原生知识库、记忆浏览器，以及轨迹复盘。这值得构建，因为信息流一直把连续性视为缺失的基础设施，而不是已经被模型解决的特性。
模型路由仍然依赖手工经验法则¶
严重程度：中。@levie 表示（118 次点赞、31 条回复、30,808 次浏览、93 次收藏），真正有价值的新层是把工作负载路由到正确的模型家族，而回复又补充说，任务结构也必须跟着模型调整。@DeRonin_ 表示（47 次点赞、14 条回复、1,355 次浏览、14 次收藏），他现在把大约 90% 的工作路由到 Kimi 2.6，把 Opus 或 GPT-5 留给高风险任务，再把收尾交给本地模型；@KingBootoshi 则说（112 次点赞、11 条回复、6,578 次浏览、179 次收藏），他仍会用 Opus 或 Claude Code 处理前端工作，但把 Codex 用于关键后端改动。即便是充满乐观气氛的 Kimi Code 发布，也有回复指出这个智能体在某个提示上陷入循环。当前的权宜方案，是一套手工维护的前沿模型与便宜模型路由手册，这说明经济账是真实存在的，但控制逻辑仍主要靠人工调参。
3. 人们期望的功能¶
一个能承载规划、记忆和审查的持久控制平面¶
这是一种务实需求，而不是含糊的愿望。@KingBootoshi 表示（112 次点赞、11 条回复、6,578 次浏览、179 次收藏），长时运行只有在经过详细讨论阶段、ADR 对齐和明确测试目标之后才会有效；而 @_avichawla 认为（16 次点赞、5 条回复、1,079 次浏览、16 次收藏），智能体需要访问仓库历史、事故上下文和团队以往决策，而不是只拿到终端上下文。@Vtrivedy10 表示（32 次点赞、3 条回复、2,751 次浏览、16 次收藏），轨迹是持续学习的生命线。大家显然想要一层既能存放计划、记住发生过什么，又知道该在什么时候升级给人的系统。机会：直接。
跨智能体界面的可移植技能和工作流契约¶
这种需求既务实，也带有竞争意味。@luka_bernardi 表示（50 次点赞、4 条回复、2,166 次浏览、15 次收藏），Xcode 现在内置 SwiftUI 智能体技能，并能把它导出到任何智能体；公开的 Agent Skills overview 也把技能描述成一种标准化方式，可为 Claude Code、Copilot、Cursor、VS Code、Gemini CLI 等增加能力。@TheTuringPost 把（11 次点赞、3 条回复、1,064 次浏览、17 次收藏）OpenProse 描述为可复用的工作流代码，而不是一次性提示词；@tonbistudio 分享（24 次点赞、1 条回复、1,750 次浏览、29 次收藏）的 Hermes 模板，则已经把路由和人工闸门外部化了。诉求很明确：技能和工作流逻辑应该跟着工作一起流动，而不是为每个工具重建一遍。机会：竞争型。
跨模型家族的自动路由与预算控制¶
这种需求既紧迫又高度运营化。@levie 表示（118 次点赞、31 条回复、30,808 次浏览、93 次收藏），把工作负载路由到正确的模型家族，正在成为 AI 智能体的一大难题；而 @DeRonin_ 表示（47 次点赞、14 条回复、1,355 次浏览、14 次收藏），他已经在手动把工作拆分到 Kimi 2.6、Opus 或 GPT-5，以及本地收尾模型之间。@reach_vb 建议（53 次点赞、13 条回复、1,992 次浏览、13 次收藏）采用中间态权限模式，因为无人值守运行既需要预算和控制策略，也需要模型选择。公开诉求是：要有一层路由系统，能自动决定模型、预算和审批姿态，同时不牺牲质量。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| 闭环与运行框架工程 | 方法 | (+) | 把规划、验证、轨迹和评估变成一套明确的操作闭环 | 在智能体真正跑好之前，需要 ADR、数据集，以及更多前期搭建 |
| Codex mega-thread + goal mode | 编码工作流 | (+) | 把完整上下文保留在一个讨论串里，并鼓励亲自试用和 E2E 验证 | 冗长的讨论阶段和数小时运行仍然需要耐心 |
| Kimi Code | 编码智能体 | (+/-) | 一行安装、视频输入、ACP 编辑器支持、MCP 配置、插件、subagent | 仍有回复称它在某些提示上会陷入循环失败 |
| Kimi Work | 桌面 swarm 运行时 | (+/-) | 本地 worker 并行、浏览器使用、记忆日记，以及处理高任务量时有说服力的成本故事 | 质量和路由收益仍然依赖手工拆角色和人工盯盘 |
Claude Code 权限模式（acceptEdits） |
权限控制 | (+) | 在保留受保护路径和升级机制的同时，减少审批疲劳 | 仍然需要每次会话显式选模式，并校准信任 |
| CodeRabbit Agent for Slack | 运维 / SDLC 智能体 | (+) | 把仓库、工单、文档、监控和记忆整合到一个有作用域的智能体界面里 | 需要围绕 Slack 设计工作流，并接好获批集成 |
| GMI Agent Box | 部署 / marketplace | (+) | 让团队在算力和模型基础设施之上访问、部署、上架并变现智能体 | 采用仍取决于 marketplace 信任、徽章和托管选择 |
| Hermes multi-agent workflow | 编排模板 | (+) | 提供了具体的接单、研究、路由、人工闸门和交付流水线 | 只是模板；用户仍需自行适配配置、认证和领域逻辑 |
| OpenProse | 工作流语言 | (+/-) | 可审查的 Markdown 契约、可复用程序，以及持久收据 | 仍有从业者怀疑这些契约在模型漂移下能否保持稳固 |
| SwiftUI / agent skills format | 技能封装 | (+) | 把可复用的最佳实践打包好，能在 Xcode 和其他智能体之间移动 | 标准和分发仍在不同界面之间碎片化 |
整体满意度更偏务实，而不是信仰式拥护。人们真正兴奋的是那些把结构封装起来的工具——闭环、技能、作用域、契约或部署元数据——而不是承诺一个完美的自主智能体。最清晰的迁移模式是：把高价模型留给规划和高风险工作，把便宜或本地 worker 压到有边界的执行层，把缺失的运营上下文搬进 Slack 或 marketplace 层，再把权限提示放宽到刚好足以让长时任务继续推进（@levie 表示（118 次点赞、31 条回复、30,808 次浏览、93 次收藏）；@DeRonin_ 表示（47 次点赞、14 条回复、1,355 次浏览、14 次收藏）；@reach_vb 建议（53 次点赞、13 条回复、1,992 次浏览、13 次收藏）；CodeRabbit 文档；GMI Agent Box 概览）。竞争焦点正在从“谁的模型最好”转向“谁的控制层最好”。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Kimi Code | @KimiDevs | 带 CLI、ACP 编辑器支持、视频输入、插件和 subagent 的开源编码智能体 | 降低多模态编码和自定义工作流自动化的接入门槛 | TypeScript、CLI/TUI、ACP、MCP、Kimi 模型 | 已发布 | repo, site, tweet |
| Kimi Work | @Kimi_Moonshot | 可运行大规模并行 swarm、支持浏览器使用和记忆日记的桌面智能体 | 为个人操作者和小团队提供一种更适合本地环境的广域研究与执行闭环 | 桌面应用、浏览器自动化、swarm 编排、记忆系统 | 已发布 | page, tweet |
| GMI Agent Box | @gmi_cloud | 用于访问、部署、上架和变现可投入生产智能体的平台 | 为智能体构建者把算力、模型访问、托管和分发打包到一个发布界面里 | Docker、200+ 模型访问、区域算力、marketplace | 已发布 | docs, page, tweet |
| CodeRabbit Agent for Slack | CodeRabbit | 原生运行在 Slack 中、可调查问题、规划并在持久上下文下发起 PR 的工程智能体 | 把仓库工作与事故、工单、文档和团队记忆连接起来 | Slack、GitHub、Jira、Notion、Datadog、有作用域的知识库 | Beta | docs, tweet |
| Hermes multi-agent workflow | @tonbistudio | 带路由和一个人工审批闸门的可复用自治分诊流水线 | 为团队提供一个具体的编排骨架，而不是临时拼凑多智能体提示词 | Python、YAML triage.yaml、Hermes Kanban |
已发布 | repo, tweet |
| OpenProse | openprose | 面向 AI 会话的声明式 Markdown 契约语言，搭配 Reactor 收据与对账 | 把脆弱的提示词工作流变成可复用、可审查的智能体程序 | Markdown .prose.md、Reactor 运行时、多运行框架支持 |
Alpha | repo, site, tweet |
| Xcode SwiftUI agent skills | @luka_bernardi | 聚焦 SwiftUI 的技能，可从 Xcode 导出到其他智能体 | 把 Apple 平台最佳实践打包成可复用的智能体指引 | Xcode、SwiftUI、agent skills | 已发布 | Apple, tweet |
Kimi Code 和 Kimi Work 展示了当天最明显的“双界面”构建模式。一边是把多模态编码推进终端和 IDE，另一边是把大范围浏览器工作和依赖记忆的 swarm 推上桌面。两者放在一起，说明开发者在尝试把高上下文编码与高吞吐并行执行拆开，而不是强迫一个界面同时承担两者。
GMI Agent Box 和 CodeRabbit Agent 则在补另一种缺口：运营胶水层。GMI 把算力、模型、托管和上架封装到一个发布界面里，而 CodeRabbit 则把仓库历史、工单、监控和团队记忆封装进一个 Slack 原生智能体。附带的 CodeRabbit 图之所以有信息量，是因为它展示的是从讨论串到计划再到 PR 的完整流程，而不是一个泛泛的聊天机器人界面。
Hermes multi-agent workflow、OpenProse 和 Xcode SwiftUI 技能，则都在把专业知识外部化成可复用工件：YAML 分诊配置、Markdown 契约，以及可安装技能。这个反复出现的构建模式很重要，因为它正好契合了当天的主导对话——先把结构固化，再让智能体在里面执行。
6. 新动态与亮点¶
Anthropic 把智能体教育做成了免费课程目录¶
@ameliahazelai 表示（70 次点赞、43 条回复、3,985 次浏览、27 次收藏），Anthropic 发布了 13 门免费课程；附图显示其中包括 Claude 101、Claude Code in Action 等 Academy 条目。Anthropic 的公开 Learn 页面 证实，新的 Academy 课程聚焦 AI 素养、API 开发、MCP 和 Claude Code。这很重要，因为到了 6 月 8 日，教育本身已经成了产品界面的一部分，而不再只是配套资源。
Apple 把智能体技能推进 Xcode，并向更广泛的智能体生态导出¶
@luka_bernardi 表示（50 次点赞、4 条回复、2,166 次浏览、15 次收藏），Xcode 现在内置 SwiftUI 智能体技能，并且可以导出给其他智能体使用。Apple 在 6 月 8 日发布的新闻稿和公开的 SwiftUI Agent Skill 仓库让这一说法变得具体：最佳实践包正在变成可安装工件，而不是只存在于本地的提示词配方。
“闭环工程”摆脱小圈子黑话，变成了共享速记¶
@gauthampai 调侃（566 次点赞、7 条回复、91,086 次浏览、24 次收藏），LinkedIn 会把“运行框架工程”叫成“闭环工程”。这个词后来也出现在 @IntuitMachine 的框架帖（33 次点赞、1 条回复、2,778 次浏览、33 次收藏）里，以及 @shannholmberg 关于开放式与封闭式 looping 的解释帖（12 次点赞、4 条回复、258 次浏览、8 次收藏）里。笑话、图示和操作者定义同时出现，使这个词本身也成了一个信号。
7. 机会在哪里¶
[+++] 面向长时程编码工作的智能体控制平面 —— 最强的证据同时来自多个部分：@KingBootoshi 表示（112 次点赞、11 条回复、6,578 次浏览、179 次收藏），在他真正信任长时运行之前，需要长讨论阶段、ADR 和亲自试用；@reach_vb 建议（53 次点赞、13 条回复、1,992 次浏览、13 次收藏）采用一种中间态审批模式；@_avichawla 认为（16 次点赞、5 条回复、1,079 次浏览、16 次收藏），严肃的智能体需要仓库、监控和工单上下文；@Vtrivedy10 表示（32 次点赞、3 条回复、2,751 次浏览、16 次收藏），轨迹是改进引擎。这组组合指向一个产品缺口：把规划、记忆、路由、审批和轨迹复盘放进同一个地方的系统。
[++] 可移植的技能和工作流工件 —— @luka_bernardi 表示（50 次点赞、4 条回复、2,166 次浏览、15 次收藏），Xcode 技能可以导出到任何智能体；公开的 Agent Skills 概览 把技能描述成跨智能体标准；而 Hermes multi-agent workflow 和 OpenProse 都把智能体逻辑变成可复用文件。这个机会处于中等强度，因为需求很明显、工件也已经出现，但生态仍然碎片化。
[++] 混合模型路由和本地 swarm 运营 —— @levie 表示（118 次点赞、31 条回复、30,808 次浏览、93 次收藏），跨模型家族路由是新的难题之一；@DeRonin_ 表示（47 次点赞、14 条回复、1,355 次浏览、14 次收藏），他已经在手工拆分 Kimi、前沿模型和本地收尾的工作；而 Kimi Code 加上 Kimi Work 又同时展示了 IDE 侧和桌面侧的产品需求。这个机会中等，因为节省是看得见的，但运营者仍然在手工制定策略。
[+] 智能体部署与分发基础设施 —— @gmi_cloud 发布（59 次点赞、27 条回复、50 次引用、7,527 次浏览）Agent Box，把托管算力和 marketplace 打包在一起；@KimiDevs 宣布（346 次点赞、25 条回复、11,343 次浏览、67 次收藏）推出了一个更适合分发的 Kimi Code，带插件和 ACP 支持。这个机会仍在萌芽，因为开发者显然想要封装与分发能力，但信任、徽章和运营治理看起来都还很早期。
8. 要点总结¶
- 规划和验证，是当前人们最愿意信任给自己的工作。 @KingBootoshi 表示（112 次点赞、11 条回复、6,578 次浏览、179 次收藏），他杠杆最大的工作是讨论阶段，而不是敲代码；而 《Learn Harness Engineering》 则把这种思路打包成了一门公开课程。(source)
- 信息流正在从提示工程转向闭环设计。 @IntuitMachine 总结（33 次点赞、1 条回复、2,778 次浏览、33 次收藏），这条阶梯从上下文到运行框架、再到意图、最终走向闭环工程；而 @gauthampai 调侃（566 次点赞、7 条回复、91,086 次浏览、24 次收藏），说明这个词本身已经具备 meme 属性。(source)
- 混合模型路由正在变成一类一等运营问题。 @levie 表示（118 次点赞、31 条回复、30,808 次浏览、93 次收藏），价值积累在路由层；而 @DeRonin_ 表示（47 次点赞、14 条回复、1,355 次浏览、14 次收藏），他已经在把工作拆给 Kimi、前沿模型和本地收尾。(source)
- 下一代智能体产品会是上下文封装层，而不只是新的聊天外壳。 @_avichawla 认为（16 次点赞、5 条回复、1,079 次浏览、16 次收藏），严肃的工程智能体需要监控和工单上下文；@gmi_cloud 发布（59 次点赞、27 条回复、50 次引用、7,527 次浏览）Agent Box，作为部署与分发基础设施；@tonbistudio 分享（24 次点赞、1 条回复、1,750 次浏览、29 次收藏）了一套可复用编排模板。(source)
- 教育和技能正在变成平台竞争的一部分。 @ameliahazelai 表示（70 次点赞、43 条回复、3,985 次浏览、27 次收藏），Anthropic 发布了大规模免费课程目录；而 @luka_bernardi 表示（50 次点赞、4 条回复、2,166 次浏览、15 次收藏），Xcode 现在内置可导出的 SwiftUI 智能体技能。(source)