跳转至

Twitter AI Agent - 2026-06-08

1. 人们在讨论什么

1.1 循环与 harness 工程成为构建可靠编码代理的通用语言 🡕

6 月 8 日最明显的变化,是讨论重心从泛泛而谈的提示词转向明确的循环、harness 和验证设计。共有 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 次收藏)学习 Harness Engineering,并称其为一堂免费大师课。该仓库称,这门课程包含 12 节课、6 个项目、一个 harness-creator skill,以及 14 种语言的翻译;随附图表则将 OpenAI、Anthropic 和 ThoughtWorks 的 harness 思路提炼成一份便于操作者使用的总结。

手绘的 harness engineering 示意图,对比了 OpenAI、Anthropic 和 ThoughtWorks 的方法,并列出了共同原则

@adxtyahq 补充说(64 个赞、3 条回复、1,223 次浏览、69 次收藏)分享了一组资源,链接到 Huyen Chip、OpenAI 的评测指南、Anthropic 的上下文工程文章,以及 Claude cookbook 材料。这张图之所以重要,在于它把社区正在采用的循环呈现为一种系统设计:模型、工具使用、环境、记忆、护栏和评测,而不只是又一个提示词技巧。

AI agent 循环图,展示了模型、工具、环境、记忆、护栏机制和评估

@IntuitMachine 总结道(33 个赞、1 条回复、2,778 次浏览、33 次收藏)将新的阶梯概括为:上下文工程、harness 工程、意图工程,再到循环工程,并引用 @steipete 的 推文,称工程师应该设计的是“提示代理的循环”。@Vtrivedy10 认为(32 个赞、3 条回复、2,751 次浏览、16 次收藏)则表示,长周期改进从根本上说是一个建立在追踪、评测创建和数据整理之上的数据挖掘问题。

讨论洞察: 关键的细微差别不在于“把提示词写得更好”,而在于“设计好循环,把代理放在明确约束之内,并在它偏离时挖掘追踪数据”。

与前一天对比: 6 月 7 日已经出现了公开的 harness 课程和默认改进配方。到了 6 月 8 日,讨论进一步加入了明确的操作者手册、循环工程这套术语,以及对 ADR、追踪和评测驱动迭代的更强强调。

1.2 模型路由与本地蜂群成为兼顾成本与性能的实用策略 🡕

第二个讨论簇把模型选择看作路由问题,而不是忠诚度竞赛。共有 4 条入选内容支撑这一主题,而且都聚焦于团队在接近生产环境的循环中,究竟如何混用前沿模型、更便宜的模型、本地工作器和审批模式。

@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 子代理,以及 marketplace 安装;其中一条回复还给出了当天最具体的提醒:该代理曾在一个它无法解决的提示上陷入循环。

@DeRonin_ 表示(47 个赞、14 条回复、1,355 次浏览、14 次收藏)表示,Kimi Work 改变了单人操盘的代理经济性,因为他可以把大约 90% 的工作路由给 Kimi 2.6,把 Opus 或 GPT-5 留给高风险的架构与安全任务,再把收尾工作交给本地模型。他是在回应 @Kimi_Moonshot 的 官方公告:一款具备最多 300 个并行工作器、浏览器操作能力和持续记忆日志的桌面代理。

@reach_vb 推荐(53 个赞、13 条回复、1,992 次浏览、13 次收藏)表示,他已将 Codex 默认切换到“Approve for me”,用于处理长时间运行的任务。公开的 permission-mode 文档 解释了这种模式为何能在各类编码代理中引发共鸣:acceptEdits 和其他更宽松的模式能够减少提示疲劳,同时不移除受保护路径的安全措施或升级节点。

讨论洞察: 信息流中的成本讨论,已经不再是“哪个模型胜出”,而是“哪个模型负责规划、哪个模型负责执行、它能无人值守运行多久,以及人类仍应在哪些环节介入”。

与前一天对比: 6 月 7 日已经有成本优化配方和一些 planner-worker 讨论。到了 6 月 8 日,这一话题扩展成了更明确的“前沿模型 vs. 低价模型”路由论点,并且出现了本地蜂群产品。

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 多智能体工作流,其 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 日围绕技能的讨论,重点还在独立管理器和调试器。到了 6 月 8 日,技能被推进到了 Xcode、Slack、工作流模板和部署栈中。

2. 什么让人感到挫败

审批疲劳与人工监督仍在限制代理吞吐量

严重程度:高。@KingBootoshi 表示(112 个赞、11 条回复、6,578 次浏览、179 次收藏)表示,讨论阶段是关键工作中最重要的环节,而一次顺利运行仍可能耗费一到两个小时,这意味着一旦对齐出错,代价很高。@reach_vb 推荐(53 个赞、13 条回复、1,992 次浏览、13 次收藏)之所以选择“Approve for me”,是因为每次工具调用都要批准会打断流程;公开的 permission-mode 文档 也说明了原因:这些更宽松的模式,本就是为了在保留受保护路径和升级机制的同时减少提示疲劳。人们的应对方式是提前做好计划、写 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 发布,也有回复称该代理曾在一个提示上陷入循环。当前的应对办法,是手动制定一套“前沿模型 vs. 低价模型”的路由手册,这说明经济效益确实存在,但控制逻辑仍主要靠人工调参。


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 概览 则把技能定位为一种标准化方式,可在 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. 正在使用的工具与方法

工具 类别 情绪 优势 局限
Harness 与循环工程 方法 (+) 将规划、验证、追踪和评测变成显式运行循环 想让代理运行良好,仍需 ADR、数据集和更多前期配置
Codex 超长帖 + goal mode 编码工作流 (+) 在一个线程里保留完整上下文,鼓励亲自试用和 E2E 验证 长讨论阶段和数小时运行仍需要耐心
Kimi Code 编码代理 (+/-) 一行安装、视频输入、ACP 编辑器支持、MCP 配置、插件和子代理 回复仍报告称,某些提示会让它陷入循环
Kimi Work 桌面蜂群运行时 (+/-) 并行本地工作器、浏览器操作、记忆日志,以及适合批量任务的成本优势 质量和路由收益仍取决于人工角色划分与监督
Claude Code 权限模式(acceptEdits) 权限控制 (+) 在保留受保护路径和升级机制的同时减少审批疲劳 每次会话仍需明确选模式,并校准信任程度
CodeRabbit Agent for Slack 运维 / SDLC 代理 (+) 将仓库、工单、文档、监控和记忆带入一个有范围限制的代理界面 需要围绕 Slack 设计工作流,并接入获批集成
GMI Agent Box 部署 / marketplace (+) 让团队能访问、部署、上架并通过算力和模型基础设施将代理商业化 采用仍取决于 marketplace 信任、徽章和托管选择
Hermes 多代理工作流 编排模板 (+) 提供具体的接收、研究、路由、人工审核和交付流程 只是模板;用户仍需适配配置、认证和领域逻辑
OpenProse 工作流语言 (+/-) 可审查的 Markdown 合约、可复用程序和持久回执 一些实践者仍怀疑合约在模型漂移下能否保持稳健
SwiftUI / agent skills 格式 技能打包 (+) 将可复用最佳实践打包,并可在 Xcode 与其他代理之间迁移 标准和分发方式在不同界面之间仍然碎片化

整体满意度是务实的,而不是近乎信仰式的。人们更热衷于那些能把结构打包起来的工具——循环、技能、范围、合约或部署元数据——而不是承诺造出一个完美自主代理的产品。最清晰的迁移模式是:让高价模型负责规划和高风险工作,让更便宜或本地的工作器执行边界清晰的任务,把缺失的运营上下文搬进 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 编辑器、视频输入、插件和子代理 降低多模态编码和自定义工作流自动化的配置门槛 TypeScript、CLI/TUI、ACP、MCP、Kimi models 已发布 仓库、网站、推文
Kimi Work @Kimi_Moonshot 可通过浏览器操作和记忆日志运行大规模并行蜂群的桌面代理 为个人操作者和小团队提供一种更适合本地环境的大范围研究与执行循环 桌面应用、浏览器自动化、蜂群编排、记忆系统 已发布 页面、推文
GMI Agent Box @gmi_cloud 用于访问、部署、上架和商业化生产就绪代理的平台 为代理构建者打包算力、模型访问、托管和分发能力 Docker、200+ 模型访问、区域算力、marketplace 已发布 文档、页面、推文
CodeRabbit Agent for Slack CodeRabbit Slack 原生工程代理,可调查、制定计划,并在持久上下文下创建 PR 打通仓库工作与事故、工单、文档和团队记忆 Slack、GitHub、Jira、Notion、Datadog、有范围限制的知识库 Beta 文档、推文
Hermes 多代理工作流 @tonbistudio 可复用的自主分诊流程,支持路由和一次人工审批 为团队提供具体的编排骨架,而不是临时拼接多代理提示词 Python、YAML triage.yaml、Hermes Kanban 已发布 仓库、推文
OpenProse openprose 面向 AI 会话的声明式 Markdown 合约语言,配合 Reactor 回执与协调机制使用 将脆弱的提示词工作流转化为可复用、可审查的代理程序 Markdown .prose.md、Reactor 运行时、多 harness 支持 Alpha 仓库、网站、推文
Xcode SwiftUI 代理技能 @luka_bernardi 面向 SwiftUI 的技能,可从 Xcode 导出到其他代理 将 Apple 平台最佳实践打包成可复用的代理指导 Xcode、SwiftUI、agent skills 已发布 Apple、推文

Kimi Code 和 Kimi Work 展现了当天最显眼的“双界面”构建模式。前者把多模态编码推进终端和 IDE,后者则把大范围浏览器工作和基于记忆的蜂群推向桌面。两者共同说明,构建者正在尝试把高上下文编码与高吞吐并行执行拆开,而不是强迫同一个界面同时承担两者。

GMI Agent Box 和 CodeRabbit 瞄准的则是另一个缺口:运营胶水。GMI 把算力、模型、托管和上架打包到一个启动界面中;CodeRabbit 则把仓库历史、工单、监控和团队记忆打包进一个 Slack 原生代理。随附的 CodeRabbit 图表之所以有信息量,在于它展示的是从线程到计划再到 PR 的完整流程,而不是一个泛化的聊天机器人界面。

CodeRabbit Slack agent 示意图,展示了如何从单个 Slack 线程完成调查、规划和 PR 创建

Hermes 多代理工作流、OpenProse 和 Xcode SwiftUI 技能,都把专业知识外置成可复用产物:YAML 分诊配置、Markdown 合约和可安装技能。这种反复出现的构建模式之所以重要,是因为它与当天的主导讨论完全一致——先把结构编码下来,再让代理在结构之内执行。


6. 新动态与值得关注的内容

Anthropic 把代理教育做成了免费课程目录

@ameliahazelai 表示(70 个赞、43 条回复、3,985 次浏览、27 次收藏)指出,Anthropic 已发布 13 门免费课程;随附截图展示了 Claude 101、Claude Code in Action,以及 Academy 中的其他课程。Anthropic 公开的 学习页面 证实,新的 Academy 课程聚焦 AI 素养、API 开发、MCP 和 Claude Code。这很重要,因为在 6 月 8 日,教育本身已经成为产品界面的一部分,而不再只是配套资源。

Anthropic Learn 的截图,展示了免费的 Academy 课程,包括 Claude 101 和 Claude Code in Action

Apple 把代理技能带进 Xcode,并推向更广泛的代理生态

@luka_bernardi 表示(50 个赞、4 条回复、2,166 次浏览、15 次收藏)指出,Xcode 现在内置 SwiftUI 代理技能,并可将其导出供其他代理使用。Apple 的 6 月 8 日新闻稿 和公开的 SwiftUI Agent Skill 仓库让这一说法变得具体:最佳实践包正从本地提示词配方转变为可安装产物。

“循环工程”走出小众术语圈,成了共享简称

@gauthampai 调侃道(566 个赞、7 条回复、91,086 次浏览、24 次收藏)表示,LinkedIn 会把 harness 工程改叫“循环工程”。这一说法也出现在 @IntuitMachine 的 框架帖子(33 个赞、1 条回复、2,778 次浏览、33 次收藏)以及 @shannholmberg 的 解读文章(12 个赞、4 条回复、258 次浏览、8 次收藏)中,后者讨论的是开放循环与封闭循环。玩笑、图表和操作者定义叠加在一起,让这个词本身成了一种信号。


7. 机会在哪里

[+++] Agent control planes for long-running coding work — The strongest evidence came from multiple sections at once: @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 次收藏)则表示,追踪数据是改进的引擎。这些内容共同指向一个产品缺口:在同一处整合规划、记忆、路由、审批和追踪审查的系统。

[++] Portable skills and workflow artifacts — @luka_bernardi 表示(50 个赞、4 条回复、2,166 次浏览、15 次收藏)指出,Xcode 技能可以导出到任何代理;公开的 Agent Skills 概览 将技能定位为跨代理标准;而 Hermes 多智能体工作流 和 OpenProse 则都把代理逻辑变成可复用文件。这一机会属于中等,因为需求显而易见、产物也已存在,但生态仍然碎片化。

[++] Mixed-model routing and local-swarm operations — @levie 表示(118 个赞、31 条回复、30,808 次浏览、93 次收藏)指出,跨模型家族路由正成为新的难题之一;@DeRonin_ 表示(47 个赞、14 条回复、1,355 次浏览、14 次收藏)表示,他已经在 Kimi、前沿模型和本地清理模型之间手动拆分工作;Kimi Code 和 Kimi Work 则表明,IDE 端和桌面端都存在产品需求。这一机会也属中等,因为节省成本的效果已经可见,但操作者仍需手工制定策略。

[+] Agent deployment and distribution infrastructure — @gmi_cloud 发布了(59 个赞、27 条回复、50 次引用、7,527 次浏览)将 Agent Box 定位为托管算力加 marketplace;@KimiDevs 宣布(346 个赞、25 条回复、11,343 次浏览、67 次收藏)则展示了一个更适合分发的 Kimi Code,支持插件和 ACP。这一方向仍处于早期,因为构建者显然需要打包与分发能力,但信任、徽章和运营治理看起来还不成熟。


8. 要点

  1. 规划与验证,是当前人们最愿意交给人类的工作。 @KingBootoshi 表示(112 个赞、11 条回复、6,578 次浏览、179 次收藏)表示,他最高杠杆的工作是讨论阶段,而不是敲代码;学习 Harness Engineering 则把这种思路打包成了一门公开课程。(来源)
  2. 信息流正从提示词工程转向循环设计。 @IntuitMachine 总结道(33 个赞、1 条回复、2,778 次浏览、33 次收藏)描述了从上下文工程到 harness 工程、意图工程再到循环工程的阶梯;@gauthampai 调侃道(566 个赞、7 条回复、91,086 次浏览、24 次收藏)则说明,这个词本身已经适合做成梗。(来源)
  3. 混合模型路由正成为一项一等运营问题。 @levie 表示(118 个赞、31 条回复、30,808 次浏览、93 次收藏)指出,价值正在向路由层聚集;@DeRonin_ 表示(47 个赞、14 条回复、1,355 次浏览、14 次收藏)则表示,他已经在 Kimi、前沿模型和本地清理模型之间拆分工作。(来源)
  4. 下一代代理产品将是上下文包,而不只是新的聊天壳。 @_avichawla 认为(16 个赞、5 条回复、1,079 次浏览、16 次收藏)指出,严肃的工程代理需要监控和工单上下文;@gmi_cloud 发布了(59 个赞、27 条回复、50 次引用、7,527 次浏览)将 Agent Box 定位为部署与分发基础设施;@tonbistudio 分享了(24 个赞、1 条回复、1,750 次浏览、29 次收藏)则介绍了一个可复用的编排模板。(来源)
  5. 教育与技能正成为平台竞争的一部分。 @ameliahazelai 表示(70 个赞、43 条回复、3,985 次浏览、27 次收藏)指出,Anthropic 发布了大型免费课程目录;@luka_bernardi 表示(50 个赞、4 条回复、2,166 次浏览、15 次收藏)则显示,Xcode 现在内置了可导出的 SwiftUI 代理技能。(来源)