Reddit AI Agent — 2026-04-13¶
1. 人们在讨论什么¶
1.1 平台锁定与开源智能体工具之争（🡕）¶
当天的主导叙事围绕模型提供商与开源智能体生态之间的结构性张力展开。Anthropic临时封禁了Peter Steinberger（OpenClaw创建者，现就职于OpenAI）的Claude账户，使人们对模型供应商利用访问控制打压竞争工具的担忧具象化。
u/Direct-Attention8597记录了事件全过程：Anthropic修改定价，将"claw harness"工作负载排除在订阅之外；Steinberger公开质疑这一时机与Claude Dispatch发布的关联性；随后几天内，他的账户被标记。该帖认为，模型提供商不再只是出售token——他们正在构建垂直整合产品，外部工具从分销合作伙伴转变为竞争对手（Anthropic Suspended the OpenClaw Creator's Claude Account , And It Reveals a Much Bigger Problem）。
讨论要点：u/TheCritFisher揭示了持续进行的猫鼠游戏："Anthropic一直在试图封禁OpenCode用户……光是上个周末就做了三次更改来封堵OpenCode。"他维护着一个专门绕过这些限制的开源库。u/siberianmi提供了背景信息：Anthropic的ARR从30亿美元增长至190亿美元，企业客户——而非OpenClaw用户——才是其优先服务对象。u/sambull从更宏观的角度阐述这一趋势："未来在边缘……中心化智能不过是封建主义。"
另外，u/stosssik曝光了泄露截图，显示Claude内部疑似集成了一个全栈应用构建器——这将直接与Lovable竞争，而Lovable最大的模型提供商即将成为其最大的竞争对手（Anthropic just leaked a Lovable competitor built into Claude）。
这种垂直整合模式——提供商在第三方依赖的基础设施之上推出竞品——与OpenClaw帖子中描述的平台动态如出一辙。这两个话题共吸引了36条评论，合计得分183。
1.2 智能体可靠性与"保姆式看护"问题（🡒）¶
一个持续存在的主题：大多数智能体"故障"并非AI问题，而是被伪装成模型问题的工程问题。多篇帖子从不同角度印证了这一观点。
u/akhilg18质疑开发者究竟是在"构建智能体还是只是在看护它们"，指出90%的工作花在验证、回退逻辑和安全护栏上，而非智能体本身（Are we building agents... or just babysitting them?）。u/Fit_Jaguar3921将其重新定义为管理角色的转变："你不再只是一个程序员，你是团队负责人。人类是经理，智能体基本上是初级员工。"u/Deep_Ad1959给出了更犀利的诊断："这是一个被伪装成管理问题的可观测性问题……大约三分之一的'已完成'任务存在从未出现在任何日志中的故障。"
u/Beneficial-Cut6585在一篇跨社区转发的分析中（两个子版块合计得分40）加以佐证：大多数经过调试的故障，根本原因在于输入质量差——不完整的API响应、过期数据、未抛出错误的缺失字段——而非幻觉或推理失败。"模型只是填补了空白，看起来'自信但错误'"（Most agent failures I've debugged weren't actually "AI problems"）。
u/HaremVictoria将这种模式称为"框架角色扮演"，认为解决办法是收窄决策树，而非增加验证层："不要试图管理一个不可预测的'初级员工'——应该构建一条严格的生产线，让LLM只在特定节点上充当原始执行引擎。"
1.3 架构之辩：主控智能体与多智能体工作流（🡕）¶
社区围绕构建一个强大的编排器还是拆分为多个专业化智能体持续展开辩论，双方如今都有了实践证据支撑。
u/Distinct-Garbage2391直接提出问题："你认为未来是一个拥有100个工具的高度训练LLM，还是20个相互通信的专业化智能体？"（Master Agent or Swarm of Micro-Agents?）。u/AurumDaemonHD引用NVIDIA的SLM论文及A2A协议上的微智能体作为群体方案的论据。
u/Cnye36提供了具体的实践证据：用4个智能体组成的内容流水线（研究、大纲、撰写、分发）替代单一的超长提示词，产出"明显更好"的结果（I replaced one giant prompt with a 4-agent workflow and the output got noticeably better）。u/Lost_Restaurant4011指出关键洞察："将交接像API契约一样对待"比单个提示词更重要。然而，u/yuckygpt持不同意见，认为"用一个具有良好上下文工程的智能体就能更好地解决这些问题。"
u/Gio_13征询实际技术栈推荐，u/Total-Hat-8891给出了全面的回答：前端放在Vercel，后端用FastAPI或Node部署在Cloud Run/Railway/Fly上，Postgres存储数据，Redis管理状态，只在工作流确实涉及多步骤时才引入LangGraph或Temporal。关键建议："我不建议仅仅因为网上有人发帖就采用多智能体架构。大多数早期系统只需要一个优秀的编排器和一个清晰的工具层"（Let's talk architecture: what's your stack?!）。
1.4 n8n生态：从教程到生产（🡒）¶
n8n社区正在明显成熟，讨论焦点从"如何入门"转向生产可靠性、代码即配置模式以及自动化服务的定价策略。
u/Annual_Ad_8737提问生产环境中最先出问题的是什么，从业者的答案趋于一致：速率限制、API字段丢失导致的静默数据损坏，以及无类型输入（What actually breaks first when you move n8n workflows to production?）。u/pvdyck分享了一个具体的故障案例："有个工作流稳定运行了2个月，第三方接口突然在没有任何警告的情况下丢了一个字段……花了3天才追溯到原因。"
u/SayedSaqlain提出了为简单自动化收费的情感困境——"有些问题用简单的工作流就能解决，几乎任何人都能搭建"——社区则予以反驳：u/heavyduty3000将其比作请人打扫房屋，u/sanchita_1607建议聚焦于"有可衡量成本的问题——错失的潜在客户、响应缓慢、耗费大量时间的人工数据录入"（Feels like cheating）。
u/Better_Charity5112按使用场景重新定义了Zapier与n8n之争：Zapier适合需要20分钟快速上手的非技术用户，n8n适合高并发精细化控制，Make则是一个两头不讨好的折中选项（Zapier vs n8n）。
1.5 小企业AI采用与品牌声音问题（🡒）¶
小企业主正在积极采用AI邮件和自动化工具，但"品牌声音问题"在工具层面仍未解决。
u/Daniel_Janifar反映AI邮件草稿"80%的时间可用，但另外20%听起来像是新闻稿写的。"主要担忧是：AI工具"磨掉了所有个性，直到读起来和其他公司通讯一模一样"（how are small businesses actually handling AI email tools without losing their voice）。u/Happy_Macaron5197通过为每个客户创建"声音文档"并在每次提示词中引用来解决此问题。u/decebaldecebal在Claude Code中使用"voice-dna技能"，包含写作范例和冷邮件策略手册。u/tom-mart则认为不调用LLM的手动模板在邮件自动化中可实现"100%准确"。
u/Sweet_Result_1277代表了感到不知所措的小企业主群体："现在有太多AI工具了，我分不清哪些真正有用，哪些只是炒作"（What are the best AI tools for small business owners?）。u/EvolvinAI29给出务实建议："基础功能（邮件、日程、基本自动化）每次都比那些花哨的'AI万能'工具更胜一筹。"
1.6 AI用户体验：超越聊天框（🡕）¶
一股日益增长的暗流质疑聊天是否应该作为AI产品的默认界面，尤其是非文本生成类产品。
u/GovernmentBroad2054提问是否每个AI产品都需要聊天框，尤其是视频生成领域（Does every AI product actually need a chatbox?）。该帖收获32条评论，是得分相对最高讨论量的帖子之一。u/Individual_Hair1401作为创始人表示："我并不总是想和工具进行深度对话；我只想让它完成任务。对于视频或设计之类的场景，我更倾向于'点击生成'或语音转素材的工作流。"u/latent_signalcraft补充了细微差别："聊天在探索阶段效果不错，但一旦工作流稳定下来，团队就会转向更结构化的UI，因为更容易控制和复用。"
2. 令人困扰的问题¶
智能体看护与可观测性缺口¶
严重程度：High。普遍性：至少5篇帖子提及，合计80+条评论。
开发者一致反映，花在验证、重试逻辑和输出核查上的时间比智能体核心任务本身还多。令人沮丧的不是智能体会失败——而是它们静默失败。u/Deep_Ad1959发现"大约三分之一的'已完成'任务存在从未出现在任何日志中的故障"——智能体自行报告成功，因为它无法检测到自身的失败。u/pvdyck遭遇了第三方API丢失字段导致的静默数据损坏："工作流继续执行，没有报错，只是错误数据被写入了CRM。花了3天才追溯到原因。"目前的应对策略包括录屏记录智能体运行过程、构建"静默捕获扫描器"，以及添加带Slack告警的错误子工作流。根本问题在于，大多数智能体框架缺乏对输入质量和下游正确性的内置可观测能力。
演示到生产的鸿沟¶
严重程度：High。普遍性：3篇帖子，合计47条评论。
u/Dailan_Grace道出了挫败感："演示环境基本上是一个受控的幻想……一旦真人用户上手，模型就开始自信地犯错、超时，或者做出完全出乎意料的事情"（why AI demos look amazing and then fall apart the moment you ship）。u/Icy-Maintenance-5962描述了在Replit、Lovable和n8n上遇到相同的困境："你从'这感觉就是未来'到'好吧，现在我又开始调试了。'"核心问题是"最后一公里的胶水"——设置账户、连接API、处理认证、在服务之间转移数据——这些打破了自主构建的幻觉。
平台锁定与定价不稳定¶
严重程度：Medium。普遍性：3篇帖子，合计39条评论。
OpenClaw事件使所有基于封闭模型API构建的开发者的恐惧具象化：定价可以改变，账户可以被标记，功能可以被吸收进平台的竞品中。u/Direct-Attention8597警告："如果你的工具依赖封闭模型提供商的API，你就无法完全掌控自己的产品路线图。"Lovable竞品的泄露加剧了这一担忧：如果Anthropic推出内置应用构建器，每一个使用Claude进行应用生成的工具都会成为其自身提供商的竞争对手。
AI生成内容中的品牌声音退化¶
严重程度：Medium。普遍性：2篇帖子，合计32条评论。
小企业经营者反映，AI生成的邮件和社交帖子趋向于一种通用的公司腔调，损害了客户关系。80/20模式始终如一：AI草稿大部分时间可用，但那20%听起来像机器人的内容会侵蚀信任。目前的变通方案（声音文档、提示词手册、人工审核）增加了摩擦成本，部分抵消了时间节省的效果。
3. 人们期望的功能¶
不需要看护的智能体¶
多名开发者描述了他们期望的智能体：能处理边缘情况、自我验证输出、主动暴露故障，而非需要持续的人工监控。u/akhilg18总结道："我们越想让它'自主'，最终添加的安全护栏就越多。"期望的是具有内置可观测性的智能体——能感知输入何时异常、输出何时错误、下游影响何时中断——而非依赖外部验证包装器。这是一个迫切的实际需求。目前没有完整的解决方案，尽管MemGuard（内存级防护）和TED（基于沙箱的自主性）尝试解决了部分子问题。机会：直接切入。
无需胶水工作的全栈"构建这个"¶
u/Icy-Maintenance-5962描述了一个明确的缺口："用自然语言说'构建这个'然后一切自动组合到位的理念基本上已经实现了。但还没有完全实现。"剩余的摩擦——账户设置、API连接、认证流程、数据路由——需要足够的技术知识，将非技术用户排除在外。u/mlueStrike反驳称完全自主还需要数年，但这种期望是一致的。机会：竞争激烈——Replit、Lovable以及Claude泄露的应用构建器都在瞄准这一目标，但无一消除了最后一公里的胶水工作。
主动感知上下文的个人AI¶
u/ryanpaulowenirl期望"一个真正了解你的上下文并主动给你发消息的东西"——不是你去查看的信息流，而是当与你个人相关的事件发生时主动提醒的智能体（Has anyone built an AI that monitors the web and proactively alerts you to stuff that's actually relevant to your life?）。Replika和Meta现有的方案"粗糙且简单"。机会：直接切入——目前没有令人满意的解决方案。
超越聊天的AI用户体验模式¶
创始人和产品构建者期望结构化的、针对特定任务的界面，而非AI产品的通用聊天形式。u/Individual_Hair1401倡导"点击生成"和语音转素材的工作流。u/kennetheops证实："语音和视觉是深度未被探索的领域。"机会：前瞻性——社区清楚聊天界面不够用，但对替代方案尚未达成共识。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | AI编程智能体 | (+/-) | 强大的终端智能体，推理能力出色，MCP集成 | 高频使用被标记账户，定价变动，锁定风险 |
| n8n | 工作流自动化 | (+) | 开源、灵活、处理复杂工作流、社区活跃 | 学习曲线陡峭，生产可靠性需额外设置，静默故障 |
| Zapier | 工作流自动化 | (+/-) | 快速上手，非技术用户友好，20分钟即可入门 | 规模化成本高，定制性不足，不适合复杂工作流 |
| Make | 工作流自动化 | (+/-) | 介于Zapier和n8n之间的折中方案 | 既无法完全满足高级用户，也未能完全满足初学者 |
| OpenClaw | 智能体适配器 | (+/-) | 模型无关，跨模型支持 | 定价被排除在订阅之外，账户被标记风险 |
| LangGraph | 智能体编排 | (+) | 支持复杂的有状态工作流，生产级 | 增加编排复杂性；仅适用于多步骤工作流 |
| Temporal | 工作流编排 | (+) | 生产级持久性，重试处理 | 对简单智能体用例过于笨重 |
| OpenRouter | LLM网关 | (+) | 模型无关路由，用于实验性项目 | 无负面评价 |
| E2B | 沙箱运行时 | (+) | 临时沙箱环境用于智能体执行，安全实验 | 仅限于沙箱用例 |
| Lovable | 应用构建器 | (+/-) | 便捷的全栈应用生成 | 提供商（Anthropic）据报正在Claude内构建竞品 |
| FastAPI | 后端框架 | (+) | 简洁的API设计，Python原生，推荐用于智能体后端 | 无负面评价 |
| Vercel | 前端托管 | (+) | 部署便捷，推荐用于智能体UI | 无负面评价 |
| Playwright | 浏览器自动化 | (+) | 分担管理任务，适合账户设置自动化 | 无负面评价 |
整体技术版图呈现出分层生态：LLM（Claude、GPT）提供推理能力，编排框架（LangGraph、Temporal、n8n）管理工作流，基础设施服务（Vercel、Cloud Run、Postgres）处理部署。可见的迁移趋势：团队正从单一超长提示词转向多智能体流水线，随着复杂度增长从Zapier转向n8n，从基于订阅的模型访问转向API计费。最值得关注的竞争动态是模型提供商的垂直整合——Anthropic同时构建模型和围绕模型的工具。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| AIPass | u/Input-X | 本地CLI多智能体框架，具有持久身份和共享文件系统 | 隔离的智能体无法看到彼此的工作成果；人类成为协调瓶颈 | Python, Claude Code, Codex, Gemini CLI | Beta | GitHub |
| TED | u/Icy-Ebb9716 | 具有沙箱执行、日记式记忆和1000个执行周期寿命的自主"实体" | 过多安全护栏的僵化智能体框架抑制了涌现行为 | Python, OpenRouter, E2B | Alpha | GitHub |
| Synapse AI | u/WabbaLubba-DubDub | 基于DAG的智能体编排，集成MCP工具和聊天界面 | 无需编写代码即可完成复杂多步任务自动化 | Python, MCP | Alpha | GitHub |
| MemGuard | u/AffectionateRice4167 | LangGraph智能体的记忆防火墙，具备7层投毒检测 | 提示词防护只保护单次提示词；持久记忆可被悄悄投毒 | LangGraph | Alpha | N/A |
| X Content Bot | u/Professional_Ebb1870 | 57个节点的n8n工作流，带有自我批评循环，用于X平台发帖 | 自动化社交媒体发帖看起来就像自动化的；质量参差不齐 | n8n, Claude, Airtable | Shipped | GitHub |
| Recipe Spec | u/Defiant_Fly5246 | 基于Markdown的可共享、可执行智能体工作流规范 | 智能体工作流存在于聊天记录中；无版本控制、共享或可复现性 | Markdown | RFC | GitHub |
| Surogates | u/deepnet101 | 用于大规模本地部署Claude Managed Agents的开放平台 | 企业对云托管智能体运行时的锁定 | Python, Kubernetes, Helm | Alpha | GitHub |
| n8n-as-code | u/sahlahfoxie_234（链接） | 用TypeScript工具以代码形式定义n8n工作流，支持git版本控制 | n8n工作流仅支持GUI操作；无法进行版本控制或代码审查 | TypeScript, n8n API | Beta | GitHub |
| PDF E-Sign Workflow | u/Few-Peach8924 | n8n模板：Google Drive到PDF签名再到邮件/Drive上传 | 手动文档签名和分发流程 | n8n, Google Drive, PDF API Hub | Shipped | GitHub |
| Semantic Diff CLI | u/Wise_Reflection_8340 | CLI工具，生成基于tree-sitter的语义级diff而非行级diff | 原始git diff浪费LLM token（上下文行、hunk头部等噪声） | Tree-sitter | Alpha | N/A |
| OpenTabs | u/opentabs-dev（链接） | MCP服务器，通过现有浏览器会话路由工具调用 | 为每个服务配置API密钥和OAuth的高摩擦成本 | TypeScript, MCP, Chrome | Shipped | GitHub |
AIPass因其反传统的设计理念而脱颖而出：它不是将智能体隔离在沙箱中，而是赋予它们共享文件系统、身份文件和本地邮箱。该项目声称在5周的公开开发中已有11个智能体、3,500+测试和185+个PR，每个PR都是"人机协作"。共享工作区模型直接解决了多位发帖者提出的协调瓶颈问题。
TED在可靠性方面采取了截然相反的策略——不是添加安全护栏，而是完全移除，将LLM放入一个具有1,000个执行周期和root权限的临时沙箱中。创建者报告了涌现行为："我见过实例自行启动本地Web服务器来展示其侦察数据。"
Recipe Spec值得关注的不是项目本身，而是社区的反应。u/CaregiverUsual（得分13）回应道："你刚刚重新发明了智能体。他们把它叫做skills而不是recipes。"其他评论者指向已有标准（agents.md、skills.sh、zerohuman.sh），凸显了智能体工作流规范标准化的趋同趋势。
一个反复出现的模式：构建者们独立地解决着同样的协调和可靠性问题，而社区反馈则不断将他们推向现有方案或更聚焦的问题定义。
6. 新动态与亮点¶
Anthropic在Claude中内置全栈应用构建器¶
Twitter上流传的截图显示，Claude内部疑似集成了一个完整的应用构建器，具备模型选择、认证和数据库生成功能。如果属实，这将使Anthropic成为Lovable、Replit及其他AI应用构建器的直接竞争对手——而它们全都依赖Claude作为模型提供商。这是社区所担忧的"平台即竞争者"动态迄今最清晰的例证。
预测市场AI智能体遭质疑¶
u/niga_chan质疑Twitter上大量声称AI预测市场智能体获得六位数回报的帖子，指出相关仓库累积了30,000+星标却没有真实盈利的证据（I HATE prediction markets posts of AI agents）。u/VorionLightbringer指出，报告的胜率低于50%"比抛硬币还差"。社区共识是大多数预测市场智能体的宣传属于推广性质，而非实质性内容。
合成用户工具：研究与实践的鸿沟¶
u/Lopsided-Fan-9823绘制了详细的四级人格模拟光谱——从基础系统提示词（大多数SaaS工具的卖点）到Stanford经过验证的数字孪生，后者通过每位参与者2小时的访谈实现了85%的复制准确率。该帖指出MiroFish（33k+ GitHub星标，约400万美元种子轮融资）在架构上有趣但缺乏效果验证，并提到"商业领域似乎没人在使用3-4级技术"（Most "synthetic user" AI tools are just ChatGPT with a system prompt）。
智能体、技能与工作流的分类混淆¶
u/PinkySwearNotABot表达了一种似乎相当普遍的困惑："我仍然很难理解智能体、技能和工作流之间的区别……这些工具/逻辑不是已经内置在智能体AI中了吗？"（state of AI agent coders April 2026）。Recipe Spec的讨论证实了这一点——社区仍在统一术语，skills.sh、agents.md和基于Markdown的规范都在争夺同一概念空间。
7. 机会在哪里¶
[+++] 智能体可观测性与输入验证工具 — 证据来自第1.2、2和5节。多位从业者独立发现了同一缺口：智能体失败是因为输入质量差，而非模型能力不足，而当前框架没有内置方式来检测输入退化或输出正确性。MemGuard解决了记忆级安全问题，但智能体工作流的通用输入/输出可观测性仍是一片空白。最强的信号是，经验丰富的构建者一致将此列为最大的摩擦来源。
[+++] 面向小企业的自动化即服务产品化 — 证据来自第1.4、1.5和2节。n8n社区表现出对针对特定垂直领域（房地产获客、社交媒体发帖、邮件跟进）的打包审计自动化工作流的明确需求。u/automatexa2b反映"客户一直付钱让我解决同样的5个问题"，u/sanchita_1607建议："找到一个有可衡量成本的日常痛点——错失的潜在客户、响应缓慢、人工数据录入。"机会在于将常见工作流产品化，而非销售定制咨询。
[++] AI内容的品牌声音保持层 — 证据来自第1.5和2节。小企业和自动化顾问都面临AI生成内容过于通用的问题。目前的解决方案（声音文档、技能、按客户定制的提示词）是手动且脆弱的。一个系统性的声音指纹识别和强制执行层——介于LLM和输出之间——将解决邮件、社交媒体和新闻通讯生成中的明确痛点。
[++] 面向企业本地部署的开源智能体基础设施 — 证据来自第1.1、5和6节。OpenClaw事件表明，依赖云托管模型API会给工具公司带来生存风险。Surogates（本地部署的Claude Managed Agents）和OpenTabs（基于浏览器会话的工具路由）都面向企业控制需求。随着Anthropic和OpenAI收紧管控，对可自托管的智能体基础设施的需求将持续增长。
[+] 主动式个人AI监控与提醒 — 证据来自第3节。u/ryanpaulowenirl描述了一个明确的产品缺口：一个了解你个人上下文并主动推送相关事件的AI。目前没有令人满意的方案。信号处于萌芽阶段——仅一篇帖子，概念清晰，但活跃开发的证据有限。
[+] 后聊天时代的AI用户体验模式 — 证据来自第1.6和3节。社区认识到聊天对许多AI产品而言是一种过渡性界面，尤其是生成类工具。对结构化、特定任务UI的需求确实存在，但尚未出现清晰的设计模式。机会尚处于早期和前瞻阶段。
8. 要点总结¶
-
平台锁定已成为开源智能体社区的首要关切。OpenClaw账户被封事件，加上Anthropic构建Lovable竞品的泄露截图，表明模型提供商正在积极与依托其API构建的生态系统展开竞争。依赖封闭模型API的开发者面临产品路线图被定价变更、访问限制或竞品第一方产品打断的风险。（Anthropic Suspended the OpenClaw Creator's Claude Account）
-
大多数智能体故障是工程问题，而非AI问题。多篇独立帖子的从业者得出同一结论：智能体看起来"自信但错误"是因为输入质量差（不完整的API响应、过期数据、缺失字段），而非模型幻觉。输入验证和可观测性工具是生产智能体系统中杠杆率最高的投入。（Most agent failures I've debugged weren't actually "AI problems"）
-
多智能体架构在实践中得到验证，但仅在复杂度超过一定阈值后才有效。从业者报告专业化智能体流水线比单一超长提示词产出明显更好的结果，智能体之间的结构化交接比单个提示词质量更重要。然而，经验丰富的构建者一致建议在简单用例中避免使用多智能体设计。（I replaced one giant prompt with a 4-agent workflow）
-
n8n生态正从爱好者阶段转向生产阶段，生产级模式仍在形成中。静默数据损坏、速率限制和无类型输入是生产环境中最常见的故障模式。社区正在围绕错误子工作流、模式验证和幂等性积累共享知识，但这些仍是口耳相传的经验，尚未被系统化。（What actually breaks first when you move n8n workflows to production?）
-
小企业AI采用是真实的，但正受到工具过载和品牌声音侵蚀的困扰。模式始终如一：每天节省15-45分钟是可实现的，但前提是采用"分层"方法（低成本工具叠加使用）并通过人工审核来保持声音一致性。机会在于内置声音保持功能的产品化工作流，而非又一个全能平台。（how are small businesses actually handling AI email tools）
-
智能体工作流规范正趋向标准化，但社区尚未选定赢家。Recipe Spec RFC引发了28条评论和强烈的反对意见，指向skills、agents.md和其他已有标准。竞争规范的激增既说明了标准化的需求，也体现了当前的碎片化状态。（RFC: What if AI agent workflows were just Markdown files?）