# Alejandro Rioja — ZH > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/zh/ Author: Alejandro Rioja Language: zh --- ## Claude Fable 5 初体验：一位运营者的视角 Source: https://alejandrorioja.com/zh/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 是 Anthropic 能力最强的模型，在高难度、长周期的智能体任务上表现尤其突出——但它并不是默认的升级选择。它每 token 的价格更高，使用了一种新的分词器，会让你的 token 数膨胀约 30%，运行着无法关闭的常驻 thinking，还可能在分类器层面拒绝请求。对于大多数工作负载，Opus 4.8 仍然是正确的选择。只有当任务真正困难时，才动用 Fable 5。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** Fable 5 是 Anthropic 能力最强的模型，在高难度、长周期的智能体任务上表现尤其突出——但它并不是默认的升级选择。它每 token 的价格更高，使用了一种新的分词器，会让你的 token 数膨胀约 30%，运行着无法关闭的常驻 thinking，还可能在分类器层面拒绝请求。对于大多数工作负载，Opus 4.8 仍然是正确的选择。只有当任务真正困难时，才动用 Fable 5。 **【运营者视角】** 我在一个咨询品牌和一家匹克球场馆里运维着 30 多个生产级智能体，所以一个新的旗舰模型对我来说不是一个跑分——它是一笔开销，也是一次迁移。下面就讲讲我真正把 Fable 5 接入其中几个智能体时发生了什么变化，以及哪些地方我仍然保留着 Opus 4.8。 ## Fable 5 到底是什么 [Claude](/recommends/claude) Fable 5 是 Anthropic 大范围发布过的能力最强的模型。它瞄准的是难度光谱中最苛刻的那一端：深度推理和长周期智能体任务——也就是那些需要智能体在数十次工具调用之间始终守住整个计划、不让思路断线的运行。 它的 API 接口与 Opus 4.7/4.8 几乎完全一致，这让测试变得很容易。默认提供 100 万 token 的上下文窗口，每次请求最多可输出 128K token。如果你在近期的 Opus 系列上构建过任何东西，这种请求结构会让你倍感熟悉。差异藏在细节里，而细节正是钱和意外所在的地方。 提一个命名上的注意点，免得你搞混：**Mythos 5** 是同一个模型——同样的能力、同样的定价、同样的行为——只是仅通过 Anthropic 的 Project Glasswing 项目提供。如果你不在那个项目里，你想要的模型就是 `claude-fable-5`。下面所有内容对两者都适用。 ## 它真正变强的地方 我先把自己最难的智能体任务抛给了它：一个多步骤的研究与综合任务，要读一堆来源、交叉核对论断，并写出一份带引用的简报。这正是那种弱模型会漂移的活儿——大约十次工具调用之后，它们就记不清哪条论断来自哪个来源了。 Fable 5 守住了思路。综合更紧凑，引用始终牢牢挂在正确的论断上，而且它还抓出了两处来源之间的矛盾，这些是我那个 Opus 4.8 版本一直在悄悄"和稀泥"略过的。在长链条、结构化的推理上，它是实打实的进步——不是边际性的跑分提升。 这就是支持它的诚实理由。如果你的智能体的失败模式是"在最难的那 10% 上崩盘"，那么 Fable 5 能缩小那道差距。如果你的智能体只是在总结新闻邮件或起草社媒帖子，你根本感受不到差别——而且你还会为自己用不上的能力买单。 ## 没人提醒你的成本陷阱 这是一个如果你只是草草扫过发布说明就会被咬一口的点。Fable 5 搭载了一个**全新的分词器**，同样的内容分词后大约比 Opus 系列**多出 30% 的 token**。 再读一遍，因为它会和价格叠加放大。Fable 5 本来定价就在 Opus 这一档之上（每百万输入 token 10 美元，每百万输出 token 50 美元）。现在再在每条 prompt 和每次补全上叠加约 30% 的 token 膨胀。一个原封不动的工作负载——同样的 prompt、同样的输出——在迁移后可能花费明显更多，而你对智能体所做的事情还一个字都没改。 所以千万不要沿用你的旧数字。你的 `max_tokens` 设置、你的上下文窗口预算、你的每次运行成本估算——它们全都是在另一个分词器上测出来的。好消息是：当你传入 `model: "claude-fable-5"` 时，token 计数端点会返回**两种**分词器下的计数，所以你可以在动任何东西之前，先在你真实的 prompt 上测出这个差值。 ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` 我先在自己最重的那些 prompt 上跑了这个。差值并不均匀——它会因内容而异——但"预留约 30% 的额外量，再加上价格溢价"是正确的心智模型。 ## thinking 始终开启——而且你无法关闭它 在 Fable 5 上，自适应 thinking 始终在运行。相对于 Opus 系列唯一一个新的破坏性变更是：如果你发送一个显式的 `thinking: {type: "disabled"}`，你会收到一个 400。修复很简单——直接整个省略 `thinking` 参数即可——但如果你之前有为了便宜、快速的调用而显式禁用 thinking 的代码，那段代码现在会报错。 你也拿不回原始的思维链。Fable 5 会保护它：你会收到正常的 `thinking` 块，并且可以用 `display: "summarized"` 请求一份可读的摘要，但未经过滤的推理过程永远不会暴露出来。对大多数应用来说这无关紧要——需要可见性的话读摘要就行。真正要紧的地方是**多轮智能体**：当你在同一个模型上续接一段对话时，你必须把 thinking 块**原封不动地**传回去。丢掉它们或编辑它们，这一轮就会出错。如果你在构建智能体循环，请把 thinking 块当作你需要逐字向前携带的不透明 token。 ## 拒绝现在成了一个控制流问题 这是对你围绕模型编写代码的方式影响最大的变化。Fable 5 会对传入的请求运行安全分类器，主要针对研究型生物学和大部分网络安全相关内容。当一个请求被拒绝时，你会收到一个**成功的 HTTP 200**，带有 `stop_reason: "refusal"`——不是错误，也不是异常。`content` 数组可能为空。 如果你的代码在没有先检查 `stop_reason` 的情况下执行 `response.content[0].text`，那么在某个请求被拒绝的那一天，它就会崩溃。而且无害的相邻工作——合法的安全工具、生命科学任务——偶尔也会触发误报，所以这并不只是那些做可疑事情的人才会遇到的问题。 规则是：**基于 `stop_reason` 来分支，绝不要基于 `stop_details`。** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` 在生产环境中，有一条更干净的路径：一个服务端的 `fallbacks` 参数（处于 beta 阶段），它会在同一次往返中自动把被拒绝的请求重试到 `claude-opus-4-8` 上，并应用类似抵扣额度的重新计价。如果你在无人值守地运行智能体，把它接上，这样一次误报式的拒绝就不会把整个运行带进死胡同。这正是我反复重新学到的关于智能体[在生产环境中不断失败](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it)的同一个教训：模型变聪明并不会消除你处理它边缘情况的需要——它只是把边缘情况挪了个位置。 ## 另外两个迁移细节 还有几件较小的事，它们花掉了我的时间，所以别让它们再花掉你的： - **没有 assistant 预填充。** 如果你之前是通过预填充最后一轮 assistant 回合来引导输出的，那种模式没了。改用结构化输出（`output_config.format`）或系统提示词指令。 - **必须接受 30 天数据保留。** Fable 5 在零数据保留下不可用。如果你出于合规原因处于 ZDR 状态，那么 Fable 5 就无从谈起，Opus 4.8 仍是你的上限。请在你规划迁移*之前*核实这一点，而不是之后。 ## 你到底该不该切换？ 下面是我和它共处一段时间之后的运营者判断。**Fable 5 并不是默认的"升级到最新模型"目标——Opus 4.8 才是。**这让人意外，但这才是正确的框架。Opus 4.8 相对于 4.7 只是一次模型 ID 的替换，没有新的破坏性变更，它更便宜，而且对于绝大多数智能体工作，它在输出质量上根本无法与之区分。 Fable 5 凭借真正困难的任务赢得自己的位置：必须在多个步骤之间保持连贯的长周期智能体、深度多来源推理，以及那些你想要消灭的失败本身很微妙的运行。对于这些，它的能力是实打实的，值这个溢价。而对于其他一切——内容起草、分类、路由、总结——你是在用更高的价格、更多的 token，去换你根本感知不到的质量。 我最后两个都在用。我的研究与综合智能体迁到了 Fable 5。其余一切都留在 Opus 4.8 上。这种分流正是关键所在：按任务挑模型，而不是按潮流。如果你运维着一支智能体舰队，我在[我的 2026 运营者技术栈](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack)中写过的同一套纪律同样适用——把困难的活儿路由给昂贵的模型，别再为简单的活儿多花冤枉钱。 ## 运营者的结论 在你动其他任何东西之前，先在你那个唯一最难的任务上测试 Fable 5——那里才是它见效的地方，而且如果它在那里都没能拨动指针，那它在别处也不会。拿 token 计数器去跑你真实的 prompt，这样约 30% 的分词器膨胀和价格溢价就不会在账单上给你来个措手不及。在 Fable 5 触及生产的每一处，加上一个 `stop_reason: "refusal"` 检查（或服务端回退到 Opus 4.8）。然后有意识地路由：困难的那 10% 交给 Fable 5，其余交给 Opus 4.8。最好的模型不是能力最强的那个——而是与任务最匹配的那个。 --- ## AI智能体初学者终极指南：Cowork、Codex与真正完成工作的工具 Source: https://alejandrorioja.com/zh/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AI智能体是超越聊天机器人的下一步：你用普通语言给它一个目标，它就完成工作——读取文件、起草内容、整理信息、编写并运行代码。Cowork是无代码入门通道；Codex和Claude Code面向需要处理代码库的人。真正重要的技能是写出清晰、范围明确的指令，而不是学习编程。 ## Table of contents _2026年6月更新。_ **TL;DR：** AI智能体是超越聊天机器人的下一步：你用普通语言给它一个目标，它就完成工作——读取文件、起草内容、整理信息、编写并运行代码，并自行检查结果。**Cowork**是面向非技术人员的无代码入门通道；**Codex**和**Claude Code**面向需要处理代码库的人。唯一重要的技能是写出清晰、范围明确的指令，而不是学习编程。 **「作者说」** 我每天运行30多个有代码的智能体，但大多数人不需要代码就能获取80%的价值。他们需要的是一条清晰的指令和一个运行它的地方。这份指南是我会递给一位从未写过代码的聪明朋友的入门读物。 ## 「AI智能体」究竟是什么 聊天机器人回答问题。**智能体**完成任务。区别在于：智能体可以循环执行动作——读取文档、决定下一步、写入文件、运行命令、检查结果、修复问题——而不需要你指导每一个步骤。 具体来说：你不是在问「我怎么清理这张表格？」你说的是「这是表格——去掉重复项，修正日期格式，标出缺少邮件地址的行」，智能体照做，然后把清理好的文件交给你。这种转变——从「建议」到「完成的工作」——正是关键所在。 ## 两大工具家族 进入这个世界有两扇门，你只需要走与自己工作相符的那扇。 ### 第一扇门：无代码智能体（不写代码的人从这里开始） **Claude Cowork**是一个工作空间，你给Claude一个目标加上材料——文件、链接、笔记——它生成你审阅和使用的成果：草稿、摘要、计划、清理好的表格。你写的是指令，不是代码。把它想成「一位读得飞快、永不疲倦的超级助手」，而不是「一个编程工具」。 这是营销人员、创始人、运营者、写作者、分析师的正确起点——凡是工作主要由文件、研究和决策构成的人，都适合从这里出发。 ### 第二扇门：编程智能体（一旦涉及代码库，就用这类工具） **OpenAI Codex**和**Claude Code**是生活在软件构建之处的智能体——终端、IDE或云端。你描述一个改动（「加一个深色模式开关」「修复这个失败的测试」「把这个文件迁移到新API」），智能体编辑代码、运行它，反复迭代直到成功。你仍然审查所有内容；智能体负责打字。 使用它们不需要是高级工程师。很多非开发者用编程智能体来上线小型网站、把表格自动化成脚本，以及修复自己没写过的工具中的bug。但确实有一定学习曲线，所以大多数初学者最好先从第一扇门开始，等遇到真正需要代码的任务时再走第二扇门。 ## 你的第一个成果（今天就做） 选一件你经常做的小而烦人的事情。好的第一选择： - 把一份乱糟糟的会议记录转成整洁的笔记加行动清单。 - 把一份长PDF总结成5条要点和3个值得追问的问题。 - 把一封粗糙的邮件改写得清晰、亲切、不超过120字。 然后使用让智能体可靠而非碰运气的结构——**角色→输入→精确指令→约束→一次核查**： > 你是我的助手。下面粘贴了一份[会议记录/PDF/邮件草稿]。请做到：[整理成清晰笔记，附加粗体「行动清单」/总结为5条要点＋3个后续问题/改写得清晰、亲切且不超过120字]。保持我的语气。如果有任何不清楚的地方，请在开始前问我一个问题。 > > [在此粘贴你的内容] 就这样。你刚刚完成了一次任务委托。结构就是全部——无论是在Cowork、ChatGPT还是编程智能体中，效果完全一样。 ## 让智能体可靠的四段式提示词 初学者以为秘诀是某句神奇的话。不是的。秘诀是具体性。每一条可靠的智能体指令都包含四个部分： 1. **角色**——智能体在这个任务中扮演谁（「你是我的调研助手」）。 2. **背景**——材料和「为什么」（「我在为与一位金融科技创始人的销售电话做准备」）。 3. **任务**——精确、范围明确的动作（「找出三条近期融资轮的事实，并起草两个开场问题」）。 4. **约束＋核查**——格式、长度、语气，以及一条「先问再猜」的指令（「只用要点，引用来源，如果公司名称有歧义请问我一个澄清问题」）。 模糊进，模糊出。智能体能做的越多，你的清晰度就越重要——一个理解错误的聊天机器人浪费一句话；一个理解错误的智能体浪费一下午需要撤销的工作。 ## 初学者常见错误 - **把它当搜索引擎用。** 别问单行问题。给它真实的工作和真实的文件。 - **省略约束。** 「给我写个计划」会得到一堵文字墙。「给我写一页计划，包含三个阶段，每个任务有负责人」会得到可用的东西。 - **不要求核查。** 加上「如果有不清楚的地方请先问我一个问题」，你就能在智能体运行之前而不是之后发现误解。 - **让编程智能体在重要代码上无人值守地运行。** 检查diff。智能体快速且大多数情况下是对的，但「大多数情况」这个词在那句话里承担了很多分量——在任何要上线的内容上都要保持人工把关。 - **太早跳到第二扇门。** 如果你的任务是文件和决策，永远不需要打开终端。 ## 如何选择你的第一个工具 - **你的工作是文件、研究和写作** → 从**Cowork**开始（或者你已经付费的聊天产品，切换到智能体模式使用）。 - **你想构建或修复软件** → **Claude Code**或**OpenAI Codex**。 - **你想要定期运行、无需干预的工作**（每日摘要、每周报告）→ 在手动掌握提示词之后，进阶到**[定时任务](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)**。 ## AI智能体初学者常见问题——2026 ### 使用AI智能体需要会编程吗？ 不需要。Claude Cowork等无代码智能体是为非技术用户设计的——你用普通语言写指令。Codex和Claude Code等编程智能体确实有学习曲线，但即便如此，越来越多不认为自己是程序员的人也在使用它们。先从无代码开始，只在任务真正需要时才使用代码。 ### 聊天机器人和AI智能体有什么区别？ 聊天机器人回答问题；智能体完成任务。智能体可以在循环中执行一系列动作——读取、决策、行动、检查、修复——产出完成的工作而非建议。实际上，同一个产品通常两者都能做；「智能体模式」就是智能体行为。 ### Cowork比Codex更好吗？ 它们面向不同的工作，没有优劣之分。Cowork是面向文件、研究和运营的无代码工作空间。Codex（和Claude Code）是用于构建和修复软件的编程智能体。选择与你任务相符的那个。 ### 如何从AI智能体获得好的结果？ 具体性。使用四段式结构：角色、背景、精确任务，以及约束加核查。给它真实的材料，告诉它你想要的格式，并让它在开始前标注歧义。清晰的指令比任何「神奇提示词」都重要。 ### 让AI智能体自主运行安全吗？ 对于低风险、可撤销的任务（起草、摘要、整理），安全——检查输出然后继续。对于任何会改变真实系统的事情（发布代码、发送消息、删除数据），保持人工把关，在它行动之前先审查。可撤销性是正确的判断标准：一件事越容易撤销，智能体就可以越安全地拥有更多自主权。 **相关阅读：** [如何被ChatGPT回答引用](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [llms.txt实操手册](https://alejandrorioja.com/llms-txt-playbook/) · [如何使用Claude定时任务](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **想要帮助你在业务中使用智能体？** 我为运营团队构建AI智能体系统——[联系我](https://alejandrorioja.com/contact/)，或进一步了解[我的思考方式](https://alejandrorioja.com/seo-tips/)。 --- ## Anthropic如何赚钱？Claude商业模式详解 Source: https://alejandrorioja.com/zh/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic通过五个主要渠道销售其Claude AI模型的访问权限：按用量计费的API（按token付费）、消费者订阅（Claude Pro和Max）、企业方案（Team和Enterprise席位）、面向开发者的Claude Code，以及通过Amazon Bedrock和Google Vertex等云市场进行分销。API和企业业务——而非消费者应用——才是最主要的收入驱动力。 ## Table of contents _更新于2026年6月。_ **TL;DR：** Anthropic通过五个主要渠道销售其Claude AI模型的访问权限：**按用量计费的API**（按token付费）、**消费者订阅**（Claude Pro和Max）、**企业方案**（Team和Enterprise席位）、面向开发者的**Claude Code**，以及通过Amazon Bedrock和Google Vertex AI等**云市场分销**。API和企业业务——而非消费者聊天应用——才是最主要的收入驱动力。 **「运营者视角」** 我每天都在使用Anthropic的API进行开发，因此我从内部视角了解这门生意。关键在于：Anthropic是一家以企业客户（B2B）为核心的公司，消费者入口只是前台。你所使用的聊天应用是市场营销兼一条收入线；真正的钱在于开发者和企业通过API消耗token、并按规模付费购买席位。 ## Anthropic是什么 Anthropic是一家AI安全与研究公司，成立于2021年，致力于打造**Claude**系列大型语言模型。它将这些模型及其周边工具销售给消费者、开发者和企业。这是一家私营公司，获得了包括Amazon和Google在内的战略投资者的强力支持，两者同时也是其云服务和分销合作伙伴。 其产品本质是「智能即服务」：你不是购买一个装箱软件，而是租用一个能够代表你进行阅读、写作、推理和行动的模型的访问权限。以下每个渠道都是对同一核心资产的不同封装。 ## Anthropic如何赚钱？ ### 1. API（按用量计费，核心引擎） 业务的基础。开发者和公司通过API调用Claude，并**按token**付费——大致上，按输入和输出的文本块计费。价格随模型能力而变化： - **Claude Opus**（能力最强的层级）定价最高——每百万输入token数美元，输出token则是其数倍。 - **Claude Sonnet**（平衡型主力）居中。 - **Claude Haiku**（快速、低成本层级）价格最低，适合高量简单任务。 输出token比输入token贵，长上下文、prompt缓存和批量处理等功能有各自的定价。关键动态：**收入与使用量直接挂钩**。一家将Claude嵌入产品并增长至数百万用户的初创公司，每个月都会产生更多的API收入，无需Anthropic签署新合同。这种按用量计费的模式正是AI实验室谈论「运行收入」增长如此之快的原因——它随客户自身的增长而复利增长。 ### 2. 消费者订阅（Claude Pro和Max） Claude应用（网页端、桌面端、移动端）均可免费试用，重度使用者可选择付费套餐： - **Claude Pro** ——按月固定费用，获得更高的使用配额、最佳模型访问权限，以及更大上下文窗口和优先访问等功能。 - **Claude Max** ——面向突破Pro配额限制的重度用户的更高价格档位，使用空间大幅提升。 这是Anthropic最显眼的部分，但对于一家主要客户是企业的公司而言，其占比小于API和企业业务线。其战略价值在于充当漏斗和品牌展示面，而非单纯的收入来源。 ### 3. 企业版（Team和Enterprise席位） 大量持久性收入的来源。企业按**每席位**为员工购买Claude，方案专为组织设计： - **Team** ——适合小型企业：共享用量配额、集中账单管理、协作功能。 - **Enterprise** ——适合大型组织：更高安全性与合规标准、单点登录、更大上下文窗口、管理员控制及用量保障。 企业合同具有周期性，并随时间扩展（更多席位、更多用量），同时带来使收入具有粘性的转换成本。这是叠加在模型之上的经典SaaS模式。 ### 4. Claude Code（开发者工具） **Claude Code**是Anthropic的智能体编程工具——一个在终端、IDE或云端编写、编辑和运行代码的智能体。它通过相同的订阅和用量轨道变现（包含在Pro/Max/Team/Enterprise档位内，并计入你的方案配额）。从战略角度看，它具备双重价值：既是独立的收入来源，又能驱动大量高价值token使用，因为编程智能体会消耗大量的模型算力。 ### 5. 云市场分销（AWS、Google等） Anthropic不仅直接销售Claude——还通过主流云平台进行分销： - **Amazon Bedrock**和**Claude Platform on AWS** ——已在AWS上的客户可通过Amazon的基础设施和账单访问Claude。 - **Google Vertex AI**和**Microsoft Foundry** ——在Google Cloud和微软平台上实现相同的逻辑。 这些渠道在企业的云支出和采购流程所在地与其对接，降低了采用Claude的门槛。收入与平台分成，但覆盖范围巨大——而Amazon和Google的深度投资使这些合作具有战略意义，而不仅仅是商业关系。 ### 6. 新兴的智能体平台 Anthropic越来越多地销售的不仅是原始的模型调用，还有**智能体基础设施**——托管服务，由Anthropic运行智能体循环并托管智能体执行任务的环境。随着越来越多的客户从「向模型提问」转向「让智能体完成工作」，这一更高层级的平台成为在按token计费核心之上创造价值的新场所。 ## Anthropic盈利了吗？ Anthropic是私营公司，不公布经审计的财务报告，但公开信息与同行相同：**收入增长极其迅速**，而公司在算力（训练和推理模型）和研究人才上花费了巨额资金。与其他前沿AI实验室一样，公司正处于大规模投入阶段，营收增长而非当期利润才是重点。投资者的押注是：随着AI渗透进更多软件，基于用量的收入将持续复利增长，最终超越算力成本。 ## 与OpenAI的对比 两者结构相似——都通过消费者订阅、按用量计费的API、企业席位和开发者工具来变现。差异在于侧重点和合作关系：Anthropic重押开发者/企业API，背靠Amazon和Google；OpenAI在消费者市场占有更大份额，并与微软建立了深度合作。如需查看对比的另一面，请参阅[OpenAI如何赚钱](https://alejandrorioja.com/how-does-openai-make-money/)。 ## Anthropic收入模式——2026年常见问题 ### Anthropic的主要收入来源是什么？ **按用量计费的API**和**企业合同**是最主要的驱动力。开发者和公司按token付费调用Claude，而组织则为其团队购买按席位计费的方案。消费者Claude订阅是最显眼的产品，但在收入中的占比小于企业业务线。 ### Claude API的定价如何运作？ 按token付费——输入和输出以文本块为单位计量。能力更强的模型（Opus）每token价格高于平衡型（Sonnet）或快速型（Haiku）模型，且输出token价格高于输入token。长上下文、prompt缓存和批量处理等功能有各自的定价。收入直接随客户使用模型的程度而增长。 ### Anthropic是上市公司吗？ 不是。Anthropic是一家私营公司，获得包括Amazon和Google在内的战略投资者和风险投资支持。其股份不在公开证券交易所上市，也没有经确认的IPO计划。 ### Anthropic能从免费的Claude应用中赚钱吗？ 不能直接从免费用户处赚钱——免费层级是一个漏斗。当免费用户升级到**Pro**或**Max**时、当团队购买**企业席位**时，尤其是当开发者基于**API**进行构建时，才会产生收入。免费应用的作用是扩大覆盖面和品牌影响力；付费层级和API才是转化发生的地方。 ### Anthropic最大的客户是谁？ 主要是其他企业：通过API将Claude嵌入自身产品的软件公司，以及将Claude部署给员工使用的企业。通过AWS、Google和Microsoft云市场进行的分销，也吸引了大量通过现有云服务商进行采购的大型企业客户。 **相关阅读：**[OpenAI如何赚钱](https://alejandrorioja.com/how-does-openai-make-money/) · [AI智能体入门指南](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [如何在ChatGPT回答中被引用](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## 简短版本 Anthropic出租其Claude模型的访问权限。开发者通过API按token付费，消费者每月为Pro和Max付费，企业为Team和Enterprise按席位付费，工程师在同一方案下使用Claude Code，而云巨头（AWS、Google、Microsoft）则通过其市场将Claude转售给企业。这是一门以企业为核心的B2B业务，消费者端只是前台入口——计量器，而非聊天应用，才是钱所在的地方。 --- ## OpenAI如何赚钱？ChatGPT与API的商业模式 Source: https://alejandrorioja.com/zh/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI主要通过四种方式赚钱：ChatGPT订阅（Plus、Pro、Team、Enterprise、Edu）、开发者按Token付费的API、大型企业合同，以及与微软的合作伙伴关系（分销加收入分成协议）。与大多数AI实验室不同，OpenAI的消费者订阅业务是其最大的单一收入来源——ChatGPT的规模就是这台引擎。 ## Table of contents _更新于2026年6月。_ **TL;DR：**OpenAI主要通过四种方式赚钱：**ChatGPT订阅**（Plus、Pro、Team、Enterprise、Edu）、**按Token计费的API**（开发者按使用量付费）、大型**企业合同**，以及**与微软的合作伙伴关系**（分销加收入分成协议）。与大多数AI实验室不同，OpenAI的消费者订阅业务是其最大的单一收入来源——ChatGPT的庞大规模正是这台驱动引擎。 **【运营者视角】**OpenAI与典型的企业AI公司恰好相反：它先打造了一个消费者现象，其次才建立起面向开发者和企业的业务。数亿ChatGPT用户既是品牌，也是现金流的来源。这个领域的所有其他玩家都希望拥有这样的顶层流量入口。 ## OpenAI是什么？ OpenAI是**ChatGPT**和**GPT**系列模型背后的AI研究公司，旗下还有Sora视频模型、图像生成和Codex编程助手等产品。公司成立于2015年，2022年底ChatGPT上线后迅速引发广泛关注，成为历史上增长最快的消费类产品之一。 其架构颇为独特：最初以非营利组织形式成立，后来建立了一个有限盈利的商业部门，以筹集训练前沿模型所需的巨额资金。公司尚未上市，与**微软**建立了深度的多年合作伙伴关系，后者提供算力、分销渠道和资本。与所有AI实验室一样，其产品本质是「智能即服务」——通过消费者、开发者和企业三大渠道销售。 ## OpenAI如何赚钱？ ### 1. ChatGPT订阅（最大收入来源） 这正是OpenAI有别于同行的地方。ChatGPT免费可用，付费套餐将其庞大用户群中的一部分转化为经常性收入： - **ChatGPT Plus** — 固定月费，可使用最优质的模型、更高的使用上限和高级功能。面向大众市场的套餐。 - **ChatGPT Pro** — 面向重度用户的高价套餐，提供最大使用量和最强大的模型设置。 - **ChatGPT Team** — 面向小型企业的按席位计费方案，含共享工作区和管理工具。 - **ChatGPT Enterprise** — 面向大型组织：高级安全性、合规性、SSO、更大上下文窗口和使用量保障。 - **ChatGPT Edu** — 专为高校和学校定制的版本。 由于ChatGPT每周活跃用户多达数亿，即便付费转化率只有个位数的低比例，也能带来庞大的订阅收入。这种消费者规模是OpenAI的决定性优势，据报道订阅收入也是其最大的营收来源。 ### 2. API（按使用量计费，面向开发者） 开发者和企业将OpenAI的模型嵌入自己的产品，按**Token**付费——即按处理的每段文本（或图像、音频）收费。定价随模型能力提升：旗舰推理模型的每Token成本高于更小、更快、更便宜的模型，且输出定价高于输入。 API将每家基于GPT构建产品的公司变成按量计费的客户，其账单随自身使用量增长而增长。这与每家AI实验室所依赖的复利动态相同：一家嵌入OpenAI并扩展至数百万用户的初创公司，每个月无需新合同便能自动产生更多API收入。 ### 3. 企业合同 除自助API和Team套餐外，OpenAI还与大型公司签订大型定制协议——批量使用、专属算力、定制支持以及安全合规承诺。这类合同具有循环性，会随时间扩展，一旦企业在模型之上构建了关键业务流程便难以替换。这一企业市场动作与消费者业务并行，是重要的增长领域。 ### 4. 与微软的合作伙伴关系 微软是OpenAI最重要的战略合作伙伴，双方关系在多个维度展开： - **算力** — 微软Azure云提供OpenAI训练和部署模型所需的大部分基础设施。 - **分销** — OpenAI的模型通过微软平台（Azure AI服务、Copilot产品）提供，将GPT推送至微软庞大的企业客户群。 - **收入分成** — 两家公司在商业协议框架下共享收入，微软也对OpenAI进行了大规模投资。 这一合作伙伴关系既是资本层面的，也是市场拓展层面的：它使OpenAI能够接触到直接销售可能需要多年才能触达的企业客户。 ### 5. 新兴和周边产品 OpenAI持续扩大可变现的业务边界： - **Codex** — 其智能编程工具，通过订阅和API使用变现（也是Token消耗的重要驱动力）。 - **Sora** — 视频生成，内置于付费套餐，也作为独立产品提供。 - **图像生成及其他模态** — 捆绑于订阅，并通过API按量计费。 - **开发者/智能体生态** — 自定义GPT、智能体平台，以及让企业基于OpenAI模型进行构建的工具。 每一项都是对同一核心资产的又一层封装，目标是捕获用户和开发者愿意付费的更多价值。 ## OpenAI盈利了吗？ OpenAI是私营公司，不发布经过审计的财务报表。广泛流传的情况是：**收入非常可观且增长迅速**，但成本同样如此——训练前沿模型并服务数亿用户需要消耗惊人的算力。与同行一样，OpenAI正处于大规模投入阶段，优先目标是增长和能力建设，而非短期盈利。其押注逻辑是：规模加上企业采用率的持续提升，终将超越算力成本。 ## 与Anthropic相比如何？ 两者的基本构成相似——消费者订阅、按量计费API、企业合同、编程工具——但侧重点不同。OpenAI的决定性优势是**消费者规模**（ChatGPT）及其与**微软**的合作；Anthropic更侧重**开发者/企业API**，背后是亚马逊和谷歌的支持。欲了解对比的另一面，请参阅[Anthropic如何赚钱](https://alejandrorioja.com/how-does-anthropic-make-money/)。 ## OpenAI收入模式——2026年常见问题 ### OpenAI最大的收入来源是什么？ **ChatGPT订阅。**由于ChatGPT覆盖数亿用户，其付费套餐（Plus、Pro、Team、Enterprise、Edu）构成了OpenAI最大的单一收入线——这对AI实验室来说是不寻常的特征，大多数实验室从API和企业业务获得的收入高于消费者。 ### OpenAI的API如何赚钱？ 开发者在自己的应用中调用OpenAI模型时，按**Token**付费——即按处理的每段文本、图像或音频收费。能力更强的模型每Token成本更高，输出定价也高于输入。随着客户自身使用量增长，收入自动增加。 ### OpenAI是否上市？我能购买OpenAI的股票吗？ 不能。OpenAI是私营公司，其股份无法在公开交易所购买。绝大多数人无法直接投资。微软通过合作伙伴关系持有重要股份，但这与OpenAI上市是两回事。 ### 与微软的合作如何为OpenAI带来收入？ 微软提供Azure算力，通过其产品和云服务将OpenAI的模型分销给庞大的企业客户群，双方在商业协议下分享收入。微软也对OpenAI进行了大规模投资。这既是资金来源，也是分销渠道。 ### OpenAI能从ChatGPT免费用户身上赚钱吗？ 不能直接赚钱——免费套餐是漏斗入口。收入来自以下几种情况：免费用户升级为**Plus**或**Pro**、企业购买**Team**或**Enterprise**席位、开发者基于**API**进行构建。免费产品的作用是触达规模，付费套餐和API负责将其转化。 **相关阅读：**[Anthropic如何赚钱](https://alejandrorioja.com/how-does-anthropic-make-money/) · [SpaceX如何赚钱](https://alejandrorioja.com/how-does-spacex-make-money/) · [AI智能体入门指南](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## 简要版本 OpenAI将ChatGPT庞大的用户群转化为订阅收入（Plus、Pro、Team、Enterprise），通过API向开发者按Token收费，签署大型企业合同，并依托微软获取算力、分销渠道和收入分成。其决定性特征是消费者规模——大多数AI实验室优先从开发者处变现；OpenAI先打造了消费者现象，再在其背后建立起商业模式。 --- ## SpaceX如何赚钱？发射业务、Starlink与IPO问题 Source: https://alejandrorioja.com/zh/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX通过三种方式赚钱：发射服务（在可重复使用的Falcon火箭上销售入轨机会）、Starlink（面向消费者、企业、海事/航空及政府的卫星互联网）以及政府合同（NASA载人和货运、月球着陆器、国家安全发射）。Starlink目前是最大的收入来源。SpaceX仍为私营公司；SpaceX本身的IPO并不迫在眉睫，不过Starlink的未来分拆上市早有讨论。 ## Table of contents _2026年6月更新。_ **TL;DR：** SpaceX通过三种方式赚钱：**发射服务**（在可重复使用的Falcon火箭上销售入轨机会）、**Starlink**（面向消费者、企业、海事/航空及政府的卫星互联网）以及**政府合同**（NASA载人和货运、月球着陆器、国家安全发射）。Starlink目前是最大的收入来源。SpaceX仍为私营公司；SpaceX本身的IPO并不迫在眉睫，不过Starlink的未来分拆上市早有讨论，且多次被泼冷水。 **【运营者解读】** SpaceX是当今最清晰的一个案例——一家公司利用硬件技术护城河（可重复使用的火箭），在其上构建了软件经济学的业务（卫星互联网）。发射业务赢得了生存权；Starlink才是持续、可扩展收入的所在。这就是整个故事的一句话总结。 ## SpaceX是什么 SpaceX（太空探索技术公司）设计、建造并飞行火箭和航天器，同时运营Starlink卫星互联网网络。该公司于2002年成立，长期目标是使人类成为多行星物种，通过做一件其他人没有大规模做到的事情——降落并重复使用轨道火箭的第一级——彻底压低了进入太空的成本，从而成为全球主导的发射服务商。 这一成本优势是一切的引擎。低廉、频繁、可靠的发射，使得由7000多颗卫星组成的星座在经济上成为可能；而这个星座，则将一个项目制的、收入不稳定的发射业务，转变为一个具有经常性收入的业务。 ## SpaceX如何赚钱？ ### 1. 发射服务 最初的业务。SpaceX向三类客户销售发射服务： - **商业卫星运营商**——需要将有效载荷送入轨道的公司，可支付费用购买专属发射，或在**拼车**任务中占据一个位置（多颗小型卫星共乘一枚火箭，按千克计价）。 - **政府和军事机构**——国家安全有效载荷和科学任务，通常因可靠性和保障需求而支付溢价。 - **其他航天公司**——包括越来越多的竞争对手，它们仍依赖SpaceX，因为这是最廉价、最易获得的发射途径。 单位经济之所以可行，在于**可重复使用性**：同一枚一级助推器可以多次飞行，因此每次发射的边际成本远低于售价。Falcon 9是主力机型；Falcon Heavy承担最重的有效载荷。 ### 2. Starlink（经常性收入的引擎） Starlink是一个由数千颗低地球轨道卫星组成的星座，向陆地宽带无法覆盖或不愿服务的地方提供高速互联网。它现在是SpaceX中最像真正订阅制业务的部分，拥有多个层次： - **消费者**——家庭用户支付天线费用（硬件）加上月度订阅费。 - **企业和移动**——面向企业、海事（船舶、游艇）和**航空**（与航空公司签订的机载Wi-Fi协议）的高价套餐。 - **政府**——包括**Starshield**，即面向军事和政府客户销售的国防导向变体。 - **直连手机**——与移动运营商合作，在盲区直接向普通手机提供卫星连接。 Starlink将硬件销售（终端设备）与数百万用户的每月经常性收入（订阅费）相结合——这是经典的「剃刀与刀片」模式，只是规模达到了行星级别。这也是为什么大多数估计现在将Starlink列为SpaceX最大的收入线，超过了发射服务。 ### 3. 政府合同 一个独立的、规模庞大的业务板块，与发射有所重叠，但值得单独拆分来看： - **NASA**——SpaceX通过**商业载人**计划（Crew Dragon）将宇航员送往国际空间站，并通过**Cargo Dragon**为其补给。公司还赢得了为NASA月球计划建造基于**Starship**的人类着陆系统的合同。 - **国家安全**——为国防和情报有效载荷提供的定期发射合同。 这些合同价值高昂、周期多年，并为商业端的大量研发提供了资金支持。 ### 4. Starship（未来的引擎，尚未成为盈利中心） Starship是SpaceX完全可重复使用的超重型运载火箭——Falcon的长期替代者，也是月球/火星任务以及下一代更大规模Starlink卫星部署的关键。目前它是一个成本中心，由其他三项业务提供资金支持。一旦实现常规飞行，它将再次大幅压低发射成本，并解锁更大规模的Starlink部署——这正是投资者真正押注的方向。 ## SpaceX盈利吗？ SpaceX是私营公司，不公布经审计的财务报告，因此任何精确数字都是估计。广为流传的图景是：得益于可重复使用性，发射业务在每次任务层面是盈利的；随着订阅用户规模扩大，Starlink已进入正现金流区间。公司将巨额资金再投入Starship的研发，因此「利润」在很大程度上取决于如何处理这部分研发支出。发展方向——在主导发射业务之上叠加不断增长的Starlink经常性收入——正是支撑公司巨额私人估值的关键所在。 ## IPO问题 这是所有人都关心的话题，以下是诚实的版本。 **SpaceX近期不太可能上市。** Elon Musk多次表示，在Starship和火星计划仍处于资本密集、长周期阶段时，他倾向于将SpaceX保持私营——公开市场的季度压力与数十年的使命不相匹配。取而代之的是，SpaceX通过定期**要约收购**（公司以固定价格促成股票出售）为员工和早期投资者提供流动性，使他们无需公开上市即可套现。这些二级销售正是产生头条估值数字的来源——SpaceX在近期融资轮次中的估值已达数千亿美元。 **Starlink分拆上市的话题由来已久**——Musk本人多年前曾暗示，一旦Starlink的收入趋于平稳且可预测，就可能考虑上市。但他也多次为近期时间表泼冷水。截至2026年，Starlink尚未IPO，也没有确认日期。除非消息来自公司本身，否则任何「Starlink IPO日期」的头条都应保持怀疑。 ## 结语 SpaceX的商业模式是一个堆栈：可重复使用的发射构建起成本护城河，这一护城河使Starlink在经济上成为可能，Starlink将整个商业版图转变为经常性收入业务，而政府合同则资助了前沿工作（Starship），后者将再次重置成本曲线。公司选择保持私营，以要约收购代替IPO——而通往公开市场的最可能路径，是未来Starlink的单独上市，而非整个SpaceX，时机由公司自行决定。 ## SpaceX收入模式——2026年常见问题 ### SpaceX最大的收入来源是什么？ 大多数估计现在将**Starlink**列为SpaceX最大的收入线，超过了发射服务，其驱动力来自数百万消费者、企业、移动端及政府订阅，以及终端硬件销售。发射服务在每次任务层面仍然规模庞大且高度盈利，但Starlink的经常性模式扩张更快。 ### SpaceX是否公开上市？我可以购买SpaceX股票吗？ 不能。SpaceX是一家私营公司，其股票无法在公开证券交易所购买。大多数人无法直接投资；通常只有员工和参与私募轮次或要约收购的合格投资者才能获得准入。请警惕任何暗示可以购买「SpaceX股票」的相关说法。 ### SpaceX或Starlink会上市吗？ 预计SpaceX近期不会上市——Musk表示希望在资本密集型的Starship/火星阶段保持私营。**Starlink** IPO多年来一直被讨论为一种可能性，等待其收入变得可预测，但截至2026年，没有确认日期。任何具体的「IPO日期」说法都应持怀疑态度，除非来自公司自身。 ### Starlink如何赚钱？ Starlink向客户收取卫星天线费用（硬件）加上月度订阅费，覆盖消费者、企业、海事、航空和政府等层级——包括国防导向的Starshield以及直连手机的运营商合作。这是「剃刀与刀片」模式：前期收取硬件费用，之后获得经常性收入。 ### 可重复使用性如何帮助SpaceX盈利？ 将同一枚火箭助推器多次降落并重新发射，使每次发射的边际成本大幅低于收取的价格。这一成本优势使SpaceX成为最廉价的发射服务商，也使部署由数千颗卫星组成的Starlink星座在经济上可行。 **相关阅读：** [Uber如何赚钱](https://alejandrorioja.com/how-does-uber-make-money/) · [Shopify如何赚钱](https://alejandrorioja.com/how-shopify-makes-money/) · [PayPal如何赚钱](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## 简短版本 SpaceX以低廉价格销售入轨机会，因为它重复使用自己的火箭，然后将这一成本优势用于运营Starlink——一项卫星互联网订阅业务，目前是其最大收入来源——同时政府合同为下一代Starship提供资金。公司有意保持私营；Starlink上市（而非SpaceX整体上市）是最终通向公开市场的最可能路径，时机将由公司自行把握。 --- ## 如何使用 Claude 定时任务：用 cron 自动化重复性工作 Source: https://alejandrorioja.com/zh/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: 定时任务将一次性的 Claude 提示词变成周期性工作：它按 cron 式计划触发，完成工作并交付结果。个人周期性提示词（早间摘要、每周汇总）使用 Claude 应用；在云端运行的开发者自动化任务使用 Claude Code 例程或 Managed Agents 部署。其价值在于将你原本每天或每周手动重复的工作自动化。 ## Table of contents _2026年6月更新。_ **TL;DR：**定时任务将一次性的 Claude 提示词变成周期性工作：它按 cron 式计划触发，完成工作并交付结果。个人周期性提示词（早间摘要、每周汇总）使用 **Claude 应用**；在云端运行的开发者自动化任务使用 **Claude Code 例程**或 **Managed Agents 部署**。其价值在于将你原本每天或每周手动重复的工作自动化。 **[运营者须知]** 杠杆效应最高的自动化往往并不炫目——它们是那些每天悄悄吃掉你20分钟的小型重复任务。定时任务就是将这些任务一次性交给 Claude、从此不必再惦记的方式。我运行了好几个：早间竞争对手扫描、夜间 PR 状态检查、每周内容管道草稿。没有一个设置超过十分钟。 ## 什么是定时任务 普通的 Claude 会话是同步的：你输入，它响应，你在场。**定时任务**是异步且周期性的：你定义一个提示词（或整个智能体工作流）加上一个计划，Claude 自行运行——每个工作日早上7点、每周一、每小时——完成后将结果交给你。 底层是以 LLM 为核心的 cron 作业。你不需要编写代码来拼接各种 API；只需用自然语言描述结果，让智能体每次触发时自己搞清楚步骤。 ## 三个设置场景 不存在单一的按钮——有三个入口，针对不同的使用者。 ### 1. Claude 应用（面向所有人） 面向消费者的 Claude 应用支持周期性任务：保存一个提示词和一个节奏，Claude 按计划运行并将结果通知你。这是无代码路径——非常适合每日简报、周期性研究检索、"每天早上汇总我未读的新闻简报"等任务。如果你不是开发者，从这里开始。 ### 2. Claude Code 例程（面向终端重度用户） 如果你使用 **Claude Code**，可以将提示词或斜杠命令安排为按 cron 节奏运行的云端智能体——即"例程"。它在服务器端的你的仓库或工作空间中运行，即使笔记本电脑关闭也照常工作。典型用途：监视开放的 pull request、执行夜间 lint 和修复扫描、每天早上生成一篇待审草稿。你定义计划和任务；Claude Code 负责触发和运行记录。 ### 3. Managed Agents 部署（面向构建产品的开发者） 对于在 Claude API 上构建产品的团队，**定时部署**按周期性 cron 计划运行智能体——每次触发都会启动一个会话，自主完成工作（夜间合规扫描、每周报告、每小时监控）。你可以获得每次触发的运行记录，以便审计成功和失败。这是同一思路的程序化、生产级版本。 ## 如何思考计划安排 三种方式共用同一套心智模型——**什么任务、多长时间一次、如何处理输出**： 1. **任务** ——按写好智能体提示词的方式来写：角色、上下文、精确动作、约束条件和一项校验。定时任务在运行中无法向你提问，因此必须*提前完整指定*。这是与交互式使用最大的区别。 2. **节奏** ——每日、每周、每小时、仅工作日、你所在时区的特定时间。让节奏与底层事物实际变化的速度相匹配；对一个每周更新一次的来源做"每日"摘要，是在浪费运行次数。 3. **交付** ——结果落地的位置（通知、文件、消息、草稿）。提前决定好，这样输出到达时就能立刻派上用场。 ## 真正值得使用的模式 - **早间摘要。**「每个工作日早上7点，获取 [主题] 的最新信息，总结三件重要的事，给我发一份5条要点的简报。」替代20分钟的手动浏览。 - **每周报告。**「每周一，将 [指标] 整理成一页摘要，包含变化内容及原因。」将重复性杂务变成一次审阅。 - **夜间工作者。**一个代码例程，在你睡觉时执行长时间、充分指定的任务——重构、测试扫描、数据清理——让你醒来就有可审阅的结果。 - **监控器。**「每小时检查 [事项]；只在 [条件] 为真时通知我。」最好的自动化大多数时候保持沉默，只在重要时才开口。 ## 来自生产环境的配置建议 - **过度指定提示词。**运行中不可能提问。要说明格式、来源、约束条件以及边缘情况的处理方式。 - **先手动测试一次。**把准确的提示词手动运行一遍。如果交互式运行产生了你想要的结果，再安排计划。如果没有，先修复提示词——给一个糟糕的提示词安排计划，只会可靠地产出糟糕的输出。 - **让节奏与变化频率匹配。**不要对每周更新一次的内容进行每小时运行。 - **高风险时将输出保留为草稿。**对于任何发布到外部世界的内容——已发布的文章、已发送的邮件——让任务生成一份供你审阅的*草稿*，而非直接执行。把完全自主的"直接做"留给低风险、可撤销的工作。 - **观察最初几次运行。**定时任务会漂移——某个来源改变了格式，某个订阅源悄然沉寂。检查早期运行记录，之后再信任它。 ## Claude 定时任务——2026年常见问题 ### 什么是 Claude 定时任务？ 它们是周期性工作：你定义一个提示词或智能体工作流加上 cron 式计划，Claude 自动执行——每日、每周、每小时——无需你守在键盘旁便可交付结果。它们存在于面向消费者的 Claude 应用中（用于个人周期性提示词）、Claude Code 中（作为云端例程）以及 Claude API 中（作为 Managed Agents 部署）。 ### 使用它们需要是开发者吗？ 不需要。Claude 应用无需代码即可支持周期性任务——只需保存一个提示词和一个节奏。Claude Code 例程和 Managed Agents 部署是面向开发者的版本，用于自动化代码和产品工作流。 ### 定时任务与普通 Claude 聊天有何不同？ 普通聊天是交互式的——你在场回答后续问题。定时任务是自主且周期性的，因此提示词必须提前完整指定；Claude 无法在运行中暂停向你提问。它按计划触发，完成工作，然后将结果交给你。 ### 什么是好的第一个定时任务？ 早间摘要。「每个工作日早上7点，将 [你的主题] 的最新信息总结成五条要点。」风险低、易于验证，能立即替代一项重复性的手动杂务——在自动化更大的事情之前，这是学习工作流程的完美模板。 ### 定时任务可以执行真实操作，比如发送邮件吗？ 可以，但要有意识地使用。对于可撤销的低风险工作，让它直接行动。对于任何面向外部或难以撤销的事情，让任务生成一份你审批的草稿，而不是自动触发——尤其是在无人值守的运行中。可撤销性是判断授予多少自主权的正确标准。 **相关阅读：**[AI 智能体入门指南](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Anthropic 如何盈利](https://alejandrorioja.com/how-does-anthropic-make-money/) · [如何被 ChatGPT 回答引用](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **想要一套管理你重复性工作的定时智能体系统？**这正是我所构建的——[联系我](https://alejandrorioja.com/contact/)。 --- ## AI 智能体的成本算账：Haiku 何时胜过 Sonnet（何时不行） Source: https://alejandrorioja.com/zh/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 选择 Claude Haiku 而非 Sonnet 可以大幅削减每次调用的成本，但前提是任务能容忍更低的成功率。真正的指标不是每次调用的成本，而是每个成功结果的成本，其中包括重试和人工善后。我按任务路由，而不是按默认值。 ## 目录 _2026 年 6 月更新。_ **摘要：** 选择 Claude Haiku 而非 Sonnet 可以把每次调用的成本削减一个数量级，但前提是任务能容忍 Haiku 更低的成功率。真正要紧的指标是**每个成功结果的成本**——调用成本加上重试再加上人工善后——而不是每个 token 的标价。我按任务路由，需要判断的环节留给 Sonnet，而相当一部分高频环节跑在 Haiku 上。 **运营者视角：** 我运行着 100 多个智能体，推理是一笔实打实的开支。但我见过一些团队把所有东西硬塞进最便宜的模型来"省钱"，然后在重试、升级和愤怒的客户身上把成本吃了回去。成本算账只有在你衡量整个漏斗时才成立。 最便宜的模型并不是每 token 单价最低的那个。而是把活儿做对所需总成本最低的那个。这是两个不同的数字，而它们之间的差距，正是大多数智能体成本决策出错的地方。 ## token 经济学，直说 Anthropic 按每百万 token 对 Claude 计费，输入和输出分开计费，输出的成本是输入的数倍。确切数字会随时间变动，所以请查阅 Anthropic 当前的定价——但驱动决策的是**结构**： - **Haiku** 是廉价、快速的档位——在整个家族中每 token 成本最低，且优势明显。 - **Sonnet** 居中——明显比 Haiku 贵，明显比 Opus 便宜。 - **Opus** 是面向最难推理的高端档位。 由此引出两点。第一，在生成类任务中，输出 token 主导成本，所以一个啰嗦的模型即便单价相同也更贵。第二，Haiku 与 Sonnet 之间的每 token 价差足够大，以至于在高频环节上一定会反映到账单上。这是支持 Haiku 的*理由*。下面是反对的理由。 ## 真正要紧的指标：每个成功结果的成本 每次调用的成本是个面子数字。这是我真正使用的公式： ``` 每成功成本 = (调用成本 × 尝试次数) + 善后成本 ÷ 成功率 ``` 其中 `尝试次数` 计入重试，`善后成本` 是由人来修复那些漏网失败的预期成本。看看这对比较起了什么作用。 假设 Haiku 每次调用的成本大约是 Sonnet 的十分之一。如果在某个任务上 Haiku 有 80% 成功、Sonnet 有 98% 成功，每次调用的节省看起来巨大。但如果 Haiku 的每次失败都触发一次重试，且每 10 次仍有 1 次需要一个花真金白银的人，善后这一项就可能吞掉 token 上的节省。在低风险、高频的任务上，算账压倒性地有利于 Haiku。在一个失败就会给错误客户发邮件的任务上，结论可能完全反转。 不衡量每个模型的成功率，你就无法做这个决定——而这正是[评估框架](/the-eval-harness-i-use-to-ship-ai-agents/)所提供的。用同一套评估集分别跑两个模型，在同一把尺子上读出成功率。 ## Haiku 决定性胜出之处 当任务**狭窄、结构化且可验证**时，Haiku 是正确选择： - **分类与路由**——"这条进来的消息是预订、投诉还是垃圾信息？"三个桶，易于验证，持续运行。整天用 Haiku。 - **带模式的抽取**——从文本中拉出一个日期、一个名字、一个金额，用 Zod 校验。如果输出能解析，几乎可以肯定是对的。 - **短改写与格式化**——语气微调、对已知良好的输入做摘要、归一化数据。 - **首轮过滤**——Haiku 做分诊，只有模糊的情形才升级到 Sonnet。这是杠杆率最高的模式。 共同的脉络：Haiku 出错的代价低，且错误便于发现。当验证便宜、风险低时，便宜的模型胜出。 ## Sonnet 值回票价之处 当任务**开放式、多步骤，或出错代价高昂**时，Sonnet（有时是 Opus）才值得： - **多工具智能体循环**，其中一次错误的工具调用会层层级联。更高的推理可靠性会跨步骤累积——我在[多智能体编排](/multi-agent-orchestration-patterns-queues-state-handoffs/)中讲到的编排模式，正依赖于模型不丢失思路。 - **面向客户的生成**，其中一次糟糕的输出损失的是信任，而不只是一次重试。 - **任何验证本身就困难的场景。** 如果你无法廉价地判断输出是否正确，你就承担不起一个经常出错的模型。 这里的失败不止一次重试的代价——它的代价是退款、流失的客户，或我的时间。相比之下，每 token 的溢价只是舍入误差。 ## 我真正上线的路由规则 我不会为每个智能体选定一个模型。我在智能体内部按**任务**路由，通常由一个廉价的分类器决定由哪个下游模型来处理： ```typescript function pickModel(task: Task): string { // 廉价、可验证、高频 → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // 开放式或面向客户 → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // 默认采用安全选项 } ``` 这里编码了两条原则。**默认选用安全的模型**，而非便宜的——你是从一个可用的基线*向下*优化成本，而不是从一个破损的基线*向上*优化可靠性。以及**升级，别赌**：让 Haiku 处理容易的 80%，把困难的 20% 交给 Sonnet。这种混合方案几乎总是胜过把所有东西单独跑在任一模型上。 此外还有提示缓存可以叠加：如果你的系统提示很大且会被重复使用，缓存会在不分档位的情况下大幅削减输入成本，这有时会让 Sonnet 便宜到使 Haiku 的取舍变得无关紧要。 ## 来自我自己技术栈的一个实例 以一个高频的进站分诊环节为例。它运行成千上万次，任务是三分类，漏判也只是让条目落入一个审核队列——便于发现、风险低。这是教科书式的 Haiku 任务，把它从 Sonnet 上挪走，在不对要紧结果造成可测量影响的前提下，明显降低了该环节的成本。 再看一个起草真正回复客户内容的环节。频率较低、开放式，而一份糟糕的草稿发出去损失的是信任。这一环节留在 Sonnet 上。同一个智能体，两个模型，按风险路由。我会盯着两者的每次运行成本和成功指标，方式如我在[我如何衡量一个 AI 智能体是否真的在起作用](/how-i-measure-whether-an-ai-agent-is-actually-working/)中所述——而且只有在评估表明更便宜的模型能保住成功率之后，我才会把某个环节降一档。 ## 常见问题 ### 在实践中 Claude Haiku 总是比 Sonnet 便宜吗？ 按 token 算，是的——而且差距很大。按每个成功结果算，则不总是。如果 Haiku 较低的成功率触发了重试和人工善后，在那些错误难以发现或修复的任务上，总成本可能超过 Sonnet。 ### 对于某个给定任务，我该如何在 Haiku 和 Sonnet 之间抉择？ 从两个维度给任务打分：输出有多可验证，以及一次错误有多昂贵。验证便宜、低风险、高频的工作交给 Haiku；开放式、面向客户或难以验证的工作交给 Sonnet。按任务路由，而非按智能体。 ### 我应该追踪的唯一成本指标是什么？ 每个成功结果的成本——调用成本乘以尝试次数加上预期善后成本，再除以成功率。单看每次调用的价格会掩盖重试和人力时间，而那正是廉价模型悄悄变贵的地方。 ### 我能在一个智能体里同时用两个模型吗？ 可以，而且通常你应该这么做。最强的模式是一次廉价的首轮处理（Haiku 做分类或过滤），只把模糊的情形升级到 Sonnet。这种混合方案通常胜过把所有东西跑在单一档位上。 --- ## 如何在生产环境中调试 AI 智能体（实战指南） Source: https://alejandrorioja.com/zh/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 调试生产环境中的 AI 智能体，主要是隔离出是哪一层出了问题——提示词、工具、模型还是编排。我用追踪 ID 记录每一步，重放完全相同的输入，然后二分定位。在我的智能体中，约 70% 的“AI 故障”最终都是管道故障，而非模型故障。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 调试生产环境中的 AI 智能体，主要是隔离出是哪一层出了问题——提示词、工具调用、模型输出还是编排。我用追踪 ID 记录每一步，重放完全相同的输入，并从那里开始二分定位。在我的智能体中，看似“AI 故障”的问题大约有 70% 最终都是管道问题：格式错误的工具结果、被截断的输入、被悄悄吞掉的异常。 **操作者视角：** 我运行着 100 多个生产智能体——Pickleland 的预订流程、内容流水线、收件箱分拣器。它们会以一切软件都会坏掉的方式坏掉，再加上几种新的方式。这是我当初希望自己拥有的实战指南：如何在不盯着一堵 token 墙的情况下找到出故障的层。 当智能体在生产环境中出问题时，本能反应是怪罪模型。“Claude 产生了幻觉。”有时确实如此。通常不是。模型只是五六层堆栈中的一层，而 bug 远更常出现在你自己写的那一层，而不是 Anthropic 交付的那一层。这篇文章讲的就是我找出它的系统化方法。 ## 在调试任何东西之前，先让每次运行都可追踪 你无法调试你看不见的东西。你能做的最具杠杆效应的事情——在任何具体 bug 出现之前——就是给每次智能体运行附上一个追踪 ID，并记录它走过的每一步。 “一步”是指任何跨越边界的东西：传入的触发器、每次模型调用（带完整的消息数组）、每次工具调用（带参数）、每个工具结果，以及最终输出。把它们记录为以追踪 ID 为键的结构化 JSON。 ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` 在 Cloudflare Workers 上，我把这些发送到队列并写入一张表；在本地它们输出到 stdout。规则是绝对的：如果某一步没有被记录，那么就调试而言它就没有发生过。这与我在[我使用的智能体技术栈](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)中描述的埋点一致——追踪 ID 是其他一切都挂靠其上的脊柱。 ## 隔离出那一层：提示词、工具、模型还是编排 一旦你有了追踪，调试就变成了二分查找。一共有四层，而大多数情况下 bug 恰好只住在其中一层。 ### 1. 输入层（最常见的元凶） 把进入失败模型调用的那个完全相同的 `messages` 数组拉出来。不是重建——而是日志里逐字逐句的载荷。然后像一个陌生人那样去读它。我那些“模型无视了指令”的 bug 中，有一半实际上是： - 一个工具结果因为某处字符串化出错而返回成了 `"[object Object]"`。 - 一个输入因为撑爆了上下文窗口、又被一次粗暴的切片砍断，从而在句子中途被截断。 - 一个变量被插值成了 `undefined`，悄无声息地毒化了提示词。 如果输入是错的，那么模型在垃圾之上完美地完成了它的工作。去修管道。 ### 2. 工具层 如果输入看起来干净，就检查是否有工具返回了一个被智能体当作成功对待的错误。一个经典案例：API 返回 `200`，正文却是 `{ "error": "rate limited" }`，而你的工具包装器没有检查正文，于是智能体自信满满地基于一条错误信息采取行动。把工具结果原样记录下来，并断言它的形状。 ### 3. 模型层 只有在排除 1 和 2 之后，我才会怀疑模型。即便如此，“模型 bug”通常意味着“我的提示词有歧义”。把那个完全相同的失败输入拿来，丢进一个针对相同模型和温度的一次性脚本，看它是否复现。如果复现，修复手段是提示词工作或一次[更严格的 eval](/the-eval-harness-i-use-to-ship-ai-agents/)，而不是慌张地换模型。 ### 4. 编排层 如果单独一步孤立来看没问题，但多步运行却失败，那么 bug 就在交接处——步骤之间丢失的状态、一个竞态条件、一次重新运行了非幂等操作的重试。这些是最棘手的，我在[多智能体编排模式](/multi-agent-orchestration-patterns-queues-state-handoffs/)中讲解了相关模式。 ## 复现非确定性，而不是与它搏斗 让智能体感觉无法调试的，是非确定性：相同的输入在不同运行间产生不同的输出。你可以驯服它。 第一，**能固定的就固定。** 调试期间设置 `temperature: 0`。这不会让 Claude 完全确定，但会大幅收窄方差，让你能把真正的 bug 与采样噪声区分开。 第二，**跑它 N 次。** 如果某个故障是每 20 次运行复现 1 次，就把那个完全相同的输入循环 50 次，并捕获每一个输出。现在你有了一个样本，而不是一则逸闻。一个 5% 概率触发的 bug 是真正的 bug——你只是需要足够的量才能看见它。 ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # 然后统计失败数 grep -c '"status":"fail"' runs.jsonl ``` 第三，**对通过的运行和失败的运行做差异比对。** 在固定温度且输入相同的情况下，输出的差异意味着存在一个你尚未发现的输入差异——提示词里的一个时间戳、一个会变化的工具结果、一个发生了变化的检索文档。 ## 搭建一个重放装置，从此不再在生产环境中调试 通过重新触发线上智能体来调试既慢又危险——它会发出真实的邮件、预订真实的场地。相反，捕获追踪并在离线状态下重放它。 重放装置加载一条已记录的追踪，重建对任意一步的完全相同的输入，并仅针对模型重新运行那一步。因为你记录了完整的 `messages` 数组，所以你根本不需要上游系统。这把生产环境中一次 10 分钟的往返变成了一个 2 秒的本地循环，是我调试工作流中最大的提速。 一个好的重放装置还让你能够**变异并重新运行**：改动系统提示词的一行，重放那同样的 50 条失败追踪，看看现在有多少条能通过。这就是从调试通向 eval 的桥梁——一旦你有了一批失败追踪的语料，你就有了一套回归测试的雏形。 ## 关注那些真正能预测崩坏的指标 有些故障从不抛出异常。智能体照常运行，返回某个看似合理的东西，却悄悄做了错事。要抓住这些，你得关注行为指标，而不只是错误率： - **工具调用成功率**（按每个工具）。这里的下降往往先于一次可见的故障。 - **输出 schema 有效性**——有多少 % 的输出能针对预期结构成功解析。我用 Zod 校验每一个输出，并在有效性下滑时告警。 - **循环长度**——每次运行的平均步数。突然的飙升通常意味着智能体卡在重试里了。 - **每次运行的成本**——一个失控的循环会先表现为成本飙升，然后才表现为一条投诉。（当成本重要时，[Haiku 对 Sonnet 的算账](/ai-agent-cost-math-when-haiku-beats-sonnet)值得了解。） 我追踪这些指标的方式和我追踪其他一切的方式一样——见[我如何衡量一个 AI 智能体是否真的在起作用](/how-i-measure-whether-an-ai-agent-is-actually-working/)。一个能抓住沉默故障的指标，抵得上十个只能抓住吵闹故障的指标。 ## 5 分钟分诊清单 当一个智能体崩了、而我又赶时间时，我会按顺序跑这套： 1. **拿到失败运行的追踪 ID。** 2. **读失败那一步的完全相同的输入。** 它格式良好吗？（在这里能解决约 50% 的情况。） 3. 在那条追踪里**检查工具结果**，找出伪装成成功的错误。 4. 在 `temperature: 0` 下**离线重放那一步。** 它复现吗？ 5. **如果复现，** 那是提示词/模型问题——修复并重跑追踪语料。**如果不复现，** 那是非确定性或状态/编排 bug——循环它 50 次来刻画它。 有纪律的隔离每一次都胜过巧妙的提示词。模型很少是问题所在；问题通常出在它周围的系统。 ## 常见问题 ### 我该如何调试一个只是偶尔失败的 AI 智能体？ 从一条已记录的追踪中捕获那个完全相同的输入，在温度 0 下重放它 50 次以上。间歇性故障是触发率很低的真正 bug——量会把逸闻变成一个可复现的样本，让你能够比对并修复。 ### bug 通常在模型里还是在我的代码里？ 在我的生产智能体中，看似的“AI 故障”大约有 70% 是管道问题：格式错误的工具结果、被截断的输入、被吞掉的异常，或步骤之间丢失的状态。在怀疑模型之前，先排除输入层和工具层。 ### 调试智能体我需要的最低限度日志是什么？ 每次运行一个追踪 ID，外加触发器、每次模型调用（完整消息数组）、每次工具调用及其原始结果、以及最终输出的结构化日志。如果一步没被记录，你就没法调试它。 ### 我该如何不再对着线上生产环境调试？ 搭建一个重放装置，它加载一条已记录的追踪，并使用捕获的输入在离线状态下重新运行任意单独的一步。它把一次缓慢、危险的生产往返变成一个快速的本地循环，并成为你回归测试套件的种子。 --- ## 如何衡量 AI 搜索是否真的在为你带来流量 Source: https://alejandrorioja.com/zh/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: 大多数 AI 搜索流量表现为来自 chatgpt.com、perplexity.ai 和 claude.ai 的涓涓引荐——但更大的影响是暗的：人们读完 AI 的回答后从不点击。我两者都衡量，用引荐来源衡量点击，用品牌搜索的提升衡量影响力。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 大多数 AI 搜索流量以来自 `chatgpt.com`、`perplexity.ai` 和 `claude.ai` 的一缕细流引荐到达——一旦你知道该看哪里就很容易统计。但更大的影响是**暗的**：人们读完 AI 的回答，吸收了你的品牌，却从不点击。我用引荐来源细分来跟踪点击，用品牌搜索提升、直接流量变化和引用监测来跟踪影响力。只统计点击会严重低估 AI 搜索。 **运营者视角：** 我运营着一台内容引擎，每天都盯着它的分析数据。"AI 搜索在带来流量吗？"这个问题有一个令人沮丧的答案：是的，但大部分价值不会出现在你的会话报告里。下面讲我如何衡量会出现的那部分，并推断不会出现的那部分。 每个人都想要一个数字——"ChatGPT 给我带来了多少流量？"。诚实的答案是，AI 搜索产生两种非常不同的效应，你需要两种不同的衡量。把它们混为一谈，你要么会恐慌（点击看起来微不足道），要么会自欺欺人（你会错过真正的影响）。 ## 效应 1：直接引荐——可统计，且比你期望的要小 当有人点击 ChatGPT、Perplexity 或 Claude 回答中的引用时，你的分析会记录一个引荐来源。这些是真实、可归因的会话。在 GA4 或任何分析工具中，构建一个捕获 AI 引擎的细分： ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` 把它保存为一个"AI 搜索"渠道并随时间观察。几个会让人栽跟头的注意事项： - **引荐来源会泄漏。** 一些 AI 界面会剥离或篡改引荐来源，因此一部分真正的 AI 点击会落到"直接"里。你的引荐计数是一个下限，而非真相。 - **相对于回答展示次数而言，量很低。** AI 引擎在页面上回答问题；只有好奇的少数人会点击进来。每天少量的引荐可能对应着远多得多的、看到你被引用的人。 所以引荐细分是必要的但不充分。它告诉你 AI 搜索正在带来*一些*流量。它严重低估了影响力。 ## 效应 2：暗影响——更大、更难看见的那一半 真正的动作是零点击。有人向 ChatGPT 提问，你的品牌作为推荐来源出现在回答中，而他从不点击——他只是记住了你。这稍后会表现为一次**品牌搜索**或一次**直接访问**，不归因于任何东西。这与让精选摘要难以衡量的动态是同一种，只是被放大了。 你无法直接衡量暗影响，但你可以三角测量它： 1. **品牌搜索量。** 在 Google Search Console 中随时间跟踪对你的名字/品牌的搜索。如果你开始被 AI 引擎引用，且你的品牌展示次数在没有相应营销活动的情况下上升，那次提升就是 AI 影响的指纹。 2. **直接流量趋势。** "直接"会话持续上升却不跟随任何营销活动，往往反映了被剥离引荐来源的 AI 引荐，加上在 AI 提及后直接输入你的人。 3. **辅助转化。** 看看 AI 搜索会话，即便罕见，是否在转化旅程中作为*第一个*触点出现。一个按末次点击微不足道的渠道，按首次触点可能很有意义。 这些都不是干净的数字。合在一起，它们告诉你暗的那一半是否在移动。 ## 跟踪引用，而不只是点击 这是我对 AI 搜索最看重的指标，而它根本不在你的分析里：**我有没有被引用，又是针对哪些查询？** 维护一份对你的业务至关重要的 20-40 个查询的清单，按计划把它们跑一遍 ChatGPT、Perplexity 和 Claude——每周一次就足够了。针对每个查询和引擎记录：你被引用了吗，在什么位置？这是排名跟踪的 GEO 版本，也是领先指标。引用的变化*先于*下游流量和品牌提升，所以在这里你能看到你的 [面向本地企业的 GEO 工作](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) 是否奏效。 我搭了一个小代理来运行这些检查并记录结果——一旦你有了代理栈，这就是件小事。如果你更愿意手动做，一个电子表格加每周 30 分钟的巡查作为起步就很好。方法论与我的 [ChatGPT 对比 Google 引用测试](/chatgpt-search-vs-google-50-term-test/) 一致，只是持续运行而非一次性。 ## 搭建仪表盘：四个数字，每周 我不会淹没在指标里。对 AI 搜索我盯着四样东西并每周复盘： 1. **AI 引荐会话**——来自引荐来源细分的可统计点击。看趋势，而非绝对值。 2. **引用覆盖率**——我在三个引擎中被引用的、被跟踪查询的百分比。领先指标。 3. **品牌搜索展示次数**——来自 Search Console，作为暗影响的代理。 4. **AI 来源转化**——即便很小，看 AI 会话是否曾经开启一段转化旅程。 如果引用覆盖率在上升而引荐会话持平，那*不是*失败——这通常意味着暗的那一半正在增长，品牌搜索数字应当随之跟上。如果引用覆盖率在下降，那是一个早期警报，要在任何流量数字变动之前采取行动。这与我应用于代理的"衡量领先指标"是同一种纪律，见 [我如何衡量一个 AI 代理是否真的有效](/how-i-measure-whether-an-ai-agent-is-actually-working/)。 ## 拿这些数字怎么办 衡量只有在改变你的做法时才有用。行动手册： - **某个你在意的查询引用覆盖率低？** 那是内容 + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/) 问题。页面要么不存在，要么没有为提取而结构化，要么不够权威而无法被拉进回答。 - **被引用了却没有引荐流量？** 在意料之中，没关系——AI 搜索在做品牌的活，不是点击的活。别靠追逐点击来"修复"它；要押注于成为被引用的来源。 - **来自一个引擎的引荐有，其他的却没有？** 各引擎在来源上分歧很大（我测得 ChatGPT 与 Google 之间约 40% 的重叠）。被一个引用并不会帮你拿下其他——分别经营每个引擎的覆盖率。 ## 关于归因诚实的一点说明 抵制住宣称你并不具备的精确度的冲动。2026 年的 AI 搜索衡量是三角测量，不是归因。任何向你兜售"ChatGPT 给你带来了 X 美元"这种干净数字的人，都是在夸大可知的范围，因为引荐来源会泄漏，而最大的效应在设计上就是零点击。正确的姿态：能数的就数，数不到的就盯着代理指标，并依据趋势做决定。即使绝对数字不可信，趋势也是可信的。 ## 常见问题 ### 我如何在 GA4 中看到来自 ChatGPT 或 Perplexity 的流量？ 构建一个把 AI 引擎域名——chatgpt.com、chat.openai.com、perplexity.ai、claude.ai、gemini.google.com、copilot.microsoft.com——作为会话来源进行匹配的渠道/细分。这能捕获点击引荐，尽管有些会被剥离到"直接"，所以把这个计数当作下限。 ### 为什么我的 AI 搜索引荐流量这么低？ 因为 AI 搜索大多是零点击——引擎在页面上回答，只有少数人点击进来。低引荐计数往往与大得多的引用展示次数同时出现。衡量引用和品牌搜索提升，以看到引荐遗漏的那部分。 ### AI 搜索最好的领先指标是什么？ 引用覆盖率：你被跟踪的、对业务至关重要的查询中，在 ChatGPT、Perplexity 和 Claude 中被引用的百分比。它先于流量和品牌提升而动，所以能早早告诉你 GEO 工作是否奏效。 ### 我能从 AI 搜索获得精确的营收归因吗？ 不能，在 2026 年无法可靠地做到。引荐来源会泄漏到"直接"，而大部分影响在设计上就是零点击。把 AI 搜索衡量当作三角测量——统计点击，盯着品牌搜索和直接流量的代理指标，依据趋势而非一个虚假精确的美元数字来做决定。 --- ## 多智能体编排模式：队列、状态与交接 Source: https://alejandrorioja.com/zh/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 可靠的多智能体系统靠的不是巧妙的提示词，而是枯燥的分布式系统纪律：智能体之间用持久队列、状态保存在模型之外、交接做到幂等以扛住重试。模型是工人，队列才是主干。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 可靠的多智能体系统不是靠巧妙的提示词赢来的，而是靠枯燥的分布式系统纪律赢来的。在智能体之间放一个持久**队列**，把**状态保存在模型之外**，并让每一次**交接都幂等**，这样重试就不会重复执行。模型是工人，队列才是主干。把这三点做对，编排就不再可怕。 **操作者视角：** 我那 100 多个智能体里，大多数都是单步的。那些不是单步的——先分类、再充实、再行动的流水线——只有当我不再把它想成"提示词链"、而开始把它想成"带 LLM 工人的任务队列"时，才变得可靠。这是架构，不是提示词工程。 "多智能体"听起来像是智能体彼此对话。实际上，可靠的版本恰恰相反：智能体根本不直接通信。它们把消息丢到队列上，再从队列里取活，编排就藏在它们之间的管道里。下面是那些能在生产环境中扛住的模式。 ## 模式 1：在每个智能体之间放一个持久队列 第一反应是从智能体 A 内部直接调用智能体 B。别这么做。直接调用把两者耦合在一起：B 慢，A 就阻塞；B 失败，A 的工作就丢了；想扩展 B，不动 A 就办不到。 正确的做法是，A 完成自己的工作，然后为 B **入队一条消息**。B 是一个独立的工人，按自己的节奏排空队列。 ```typescript // 智能体 A 完成后通过队列交接——不直接调用 B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // A 的任务已完成。B 会独立地取走它。 ``` 在 Cloudflare 上，我正是用 Workers Queues 来做这件事——和[我使用的智能体技术栈](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)背后是同样的原语。队列免费给你四样东西：**缓冲**（B 宕机也不丢工作）、**重试**（失败的消息会重新投递）、**背压**（峰值会排队而不是崩溃）和**解耦**（扩展或重新部署 B 都不必动 A）。这其中每一项，否则你都得自己手搓并搞砸。 ## 模式 2：始终把状态保存在模型之外 最常见的多智能体 bug，是假设模型在各步骤之间记得什么。它不记得。每次模型调用都是无状态的，唯一的记忆就是你放进提示词里的东西。所以"这个任务在流水线里走到哪儿了"的事实来源，必须存在数据库里，而不是对话里。 我维护一条单一的任务记录，每个智能体都读取并更新它： ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` 每个智能体都跑同一个循环：**读取**任务状态、干自己的活、**写入**新状态、把下一阶段入队。模型从不持有状态——它把相关切片作为输入接收，并返回一个结果。这正是让系统可重启的关键：如果某个工人在任务中途挂掉，状态记录仍然准确地记着事情走到了哪儿，重新投递的队列消息会从那里接手。它也让调试变得可控，因为状态表是每个任务旅程的可查询记录——这和[我如何衡量一个智能体是否真的在工作](/how-i-measure-whether-an-ai-agent-is-actually-working/)里同样的度量心态。 ## 模式 3：让每一次交接都幂等 队列保证的是*至少一次*投递，而非恰好一次。这意味着一条消息可能被投递两次——网络抖动、重试、重新部署。如果你智能体的动作不是幂等的，双重投递就会重复执行：两封确认邮件、两份预订、两笔扣款。这是最棘手的一类编排 bug，也是团队在生产环境才发现的那一类。 修复办法是用一个键让动作幂等： ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // 已经处理过这一阶段——这是重复投递。跳过。 return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` 阶段检查让操作可以安全地运行两次：第二次投递发现任务已经推进，就什么都不做。对于外部副作用（发邮件、扣信用卡），把一个幂等键传给下游 API，让*它*也去重。假设每条消息都会被投递两次，并把设计做到这无害——因为它迟早会发生。 ## 模式 4：编排者 vs 编舞——刻意做选择 接线流程有两种方式，正确的选择取决于复杂度。 **编舞**（我默认采用的）：每个智能体只知道下一步并把它入队。流程从链条中涌现。简单、去中心化、易于扩展——插入一个队列就能加一个阶段。缺点是没有一个单独的地方描述整个流程，所以复杂的流水线可能变得难以推理。 **编排**（一个中央协调者）：一个编排者掌握流程，依次调用每个智能体，并根据结果决定下一步。整个流程都住在一个可读的地方，分支逻辑是显式的。代价是一个本身必须持久的中央组件——如果编排者自己的状态没有外置（模式 2），它就成了单点故障。 我的规则：**在分支变复杂之前用编舞，之后用持久的编排者。** 一条线性的三阶段流水线是编舞。一个带条件路由、并行扇出和汇合的流程，需要一个状态存在数据库里、以便崩溃后能恢复的编排者。 ## 模式 5：扇出、扇入而不丢失任何一块 当一个任务衍生出 N 个并行子任务（充实 50 条记录、总结 20 份文档），而你需要等它们全部完成才能继续时，你就需要一次**汇合（join）**。诀窍是任务状态里的一个计数器： 1. 父任务入队 N 条子消息，并在任务记录里写入 `expected: N, completed: 0`。 2. 每个子任务干完自己的活，并**原子地递增** `completed`。 3. 把 `completed` 推到等于 `expected` 的那个子任务，把下一阶段入队。 这个原子递增是承重的——没有它，两个同时完成的子任务可能都以为自己不是最后一个，于是汇合永远不触发。用一个数据存储能原子递增的计数器，或者用一个事务。这个模式让你能把流水线中昂贵的中段并行化（往往是 Haiku 能廉价处理的活——见 [Haiku 与 Sonnet 的成本算账](/ai-agent-cost-math-when-haiku-beats-sonnet)），同时在末尾保持一次干净的汇合。 ## 我会略过的东西 做这一切，你都不需要一个重量级的智能体框架。队列、一张状态表和幂等键，都是每个平台早已具备的原语。我见过有团队为了拿到队列免费就给的功能，去搬来精心设计的多智能体框架，结果继承了一个比它所替换的管道更难调试的黑盒。从枯燥的原语开始。只有当你真切感受到某个框架能解决的具体痛点时，才去伸手拿它。 总结：智能体是无状态的工人，队列是持久的主干，状态住在数据库里，每一次交接都能安全地运行两次。这就是全部的游戏。 ## 常见问题 ### 智能体应该彼此直接调用，还是走队列？ 走队列。直接调用会耦合智能体——一方的失败或缓慢会传播到另一方，而且你无法独立扩展或重新部署。持久队列免费给你缓冲、重试、背压和解耦。 ### 多智能体状态应该存在哪里？ 存在模型之外、数据库里，作为一条每个智能体都读取并更新的任务记录。模型调用是无状态的，所以流水线进度的事实来源必须是外部的——这正是让系统在崩溃后可重启的关键。 ### 我如何防止一个智能体在同一个任务上执行两次？ 让交接幂等。行动前先检查任务的阶段，若已推进就什么都不做，并把幂等键传给外部 API。队列至少投递一次，所以假设每条消息都可能到达两次，并把设计做到重复无害。 ### 我需要一个多智能体框架吗？ 通常不需要。持久队列、一张状态表和幂等键，用你平台早已提供的原语就能覆盖大多数生产需求。只有当你撞上某个框架能独到解决的具体问题时才采用它，而不是默认就用。 --- ## 我用来无所畏惧地发布 AI 智能体的评估框架 Source: https://alejandrorioja.com/zh/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 无所畏惧地发布智能体来自一件事：一套评估框架。一组固定的评分测试用例，自动打分（断言加上一个 LLM 评判），在每次提示词或模型改动前运行。分数守住，就发布。测试集是用真实的生产故障构建的。 ## 目录 _2026 年 6 月更新。_ **摘要：** 我之所以能在一个上线的智能体上改提示词或换模型而不必屏住呼吸，靠的是一件事：一套**评估框架**。一组固定的评分测试用例，自动打分——能写硬断言的地方写硬断言，写不了的地方用 LLM 评判——在每次改动前运行。分数守住，我就发布。分数下降，我就不发。测试集不是合成的；它是用真实的生产故障构建的，所以每个 bug 都会变成一项永久的回归测试。 **操作者视角：** 在 100 多个智能体里，我有信心去碰的和我害怕去碰的，区别就在于有没有评估。没有评估框架，每一次提示词微调都是一场赌博。评估框架把"我觉得这个更好"变成"这个可量化地好了 4 分，而且什么都没弄坏"。这就是全部的解锁所在。 你不会不写测试就发布代码。人们却不停地不写评估就发布智能体，然后纳闷为什么一次"小小的提示词微调"搞坏了生产。评估框架就是为非确定性软件准备的测试套件。这是我实际运行的那一套。 ## 从真实故障构建的测试集开始 框架的好坏取决于它的测试用例，而最好的测试用例来自生产，而非你的想象。每次智能体在真实环境里失败时，我都会捕获确切的输入（我把每次运行都连同一个追踪 ID 记录下来——见[如何在生产环境中调试智能体](/how-to-debug-an-ai-agent-in-production)），并把它变成一个评估用例： ```typescript interface EvalCase { id: string; input: AgentInput; // 确切的生产输入 expected?: string; // 有标准答案时的基准真值 assertions: Assertion[]; // 必须通过的硬性检查 rubric?: string; // 用于 LLM 评判，当输出是开放式时 } ``` 这里有两条实践很重要。**从生产中提取**，这样你的评估测试的是真正会坏的东西，而不是你猜测可能会坏的东西。以及**覆盖整个范围**——正常路径、边缘情况、对抗性输入，以及那些会导致静默失败的空/格式错误输入。一套精选的 30 到 50 个用例的测试集，比 500 个敷衍的用例抓到的多得多。我宁愿有 40 个各自代表一种真实失败模式的用例，也不要一千个全都测试同一条简单路径的用例。 ## 先用断言打分，再用 LLM 评判 并非每个输出都需要一个模型来打分。我会去拿能用的最便宜的打分器。 对一切结构化的东西用**硬断言**。输出能解析为有效的 JSON 吗？包含必需字段吗？提取出的日期在范围内吗？它是否用正确的参数调用了正确的工具？这些是确定性的、免费的、毫无歧义的——能写多少就写多少。 ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` 对开放式的其余部分用 **LLM 评判**——语气、有用性、"它到底有没有回答问题"。在这里你给模型输入、输出和一份评分标准，让它打分。两条规则能让评判保持诚实：把评分标准做得**具体**（带有描述性锚点的 1 到 5 分量表胜过"给质量打分"），并用一个**强模型作为评判**——评判是一项推理任务，所以即便智能体本身按照[成本计算](/ai-agent-cost-math-when-haiku-beats-sonnet)跑在 Haiku 上，这也是我乐意为 Sonnet 付费的地方。模糊的评分标准或羸弱的评判会给你看起来像信号的噪声。 ## 在每次改动前运行框架 框架的存在是为了回答一个问题：*这次改动让智能体变好了还是变差了？* 所以我在每次提示词编辑、模型替换或工具改动之前都运行它。 ```bash # main 上的基准 npm run eval -- --suite=booking-agent > baseline.json # 做出改动，然后重新运行 npm run eval -- --suite=booking-agent > candidate.json # 比较 npm run eval:diff baseline.json candidate.json ``` 差异报告会显示汇总分数、逐用例的通过/失败，以及——至关重要的——**具体是哪些用例发生了回归。** 一个在三个用例静默损坏的同时往上走的汇总分，不是改进；那是一笔我想看到并批准的取舍，而不是悄悄溜过去的那种。盯着逐用例的差异，就是你避免"修好一个、弄坏两个"的办法——正是这种失败模式让人们害怕自己的提示词。 ## 设一道回归闸门，让它拦下来 一旦你信任了框架，就把它作为闸门接入通往生产的路径。我的规则很直白：**任何让分数跌破基准阈值的改动都不发布。** 不是"我回头看看"——而是被拦下，和一个失败的 CI 测试一样。 ```typescript const PASS_THRESHOLD = 0.90; // 90% 的用例必须通过 if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` 正是这一点把评估从一个锦上添花的东西，变成让你能快速行进的那件东西。闸门让"无所畏惧地发布"字面意义上成真：一次糟糕改动的最坏情况是一次飘红的评估运行，而不是一场生产事故。而且因为测试集每次有东西损坏时都会增长，闸门会随着时间自行变得更严格、更具保护性。 ## 在打分中考虑非确定性 一个让人栽跟头的微妙之处：同一个输入在不同运行中可能得到不同的分数，因为模型的采样方式不同。如果你每个用例只跑一次，你会看到幻影回归——一个"坏了"的用例其实只是采样噪声。 两种缓解办法。在 **`temperature: 0`** 下运行评估以缩小方差（它无法完全消除）。而对那些你见过闪烁的用例，**跑 N 次并取通过率**，而不是单次的通过/失败。一个 10 次通过 9 次的用例，状态比一个 10 次通过 5 次的更好，哪怕两者都能显示一次飘绿的单次运行。这与我[调试间歇性失败](/how-to-debug-an-ai-agent-in-production)时用的"用量胜于轶事"原则相同——一次运行是观点，五十次运行是数据。 ## 用生产监控闭合回路 评估框架针对已知用例做测试。生产则抛出新奇的用例。所以回路是这样的：监控线上行为，抓住一种新的失败模式，把它变成一个评估用例，修好它，于是它现在被永久守护了。监控这一侧——在线上流量中追踪成功率、输出有效性和每次运行的成本——是我在[我如何衡量一个 AI 智能体是否真的在工作](/how-i-measure-whether-an-ai-agent-is-actually-working/)中讲到的。评估和监控是同一系统的两半：监控找出 bug，评估确保它们保持死透。 那个反馈回路才是真正的产品。任何单一的评估集都会过时；而一个把每次生产故障都转化为永久测试的*流程*，每周都会变得更强。这就是一个智能体如何从"碰都不敢碰"变成我会在某个周五下午眼都不眨地重构的东西。 ## 常见问题 ### 一个 AI 智能体评估集里包含什么？ 把真实的生产输入变成评分用例——正常路径、边缘情况、对抗性和格式错误的输入——每个都配硬断言，对开放式输出再配一份 LLM 评判评分标准。从真实故障中提取的 30 到 50 个用例，胜过数百个全都测试简单路径的合成用例。 ### 我该用 LLM 来给智能体输出打分吗？ 凡是输出结构化的地方（有效 JSON、正确字段、正确的工具调用）都用硬断言——它们免费且确定。把 LLM 评判留给语气、有用性这类开放式特质，配上具体的评分标准和强评判模型，这样你得到的是信号，而不是噪声。 ### 我如何阻止一次提示词改动悄悄搞坏生产？ 在每次改动前运行评估框架并与基准做差异比对，盯着逐用例的回归，而不只是汇总分数。然后用结果为部署设闸，任何跌破基准阈值的改动都像失败的测试一样被拦下。 ### 我如何处理评估中的非确定性？ 在温度 0 下运行以降低方差，对会闪烁的用例，多次运行并用通过率打分，而不是单次运行。一个 10 次中通过 9 次的用例，比一个 10 次中通过 5 次的更健康，即便单次运行两者都显示为绿。 --- ## 如何用AI代理自动化你的新闻通讯 Source: https://alejandrorioja.com/zh/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Claude代理读取我的内容队列，选择本周最强的切入角度，用我的语气起草新闻通讯，按参与度层级分段列表，并通过Kit API安排发送——全程无需我打开编辑器。我查看渲染预览并点击批准。困难的创意工作是我的；机械执行是代理的。 ## 目录 _2026年6月更新。_ **TL;DR：** Claude代理读取我的内容队列，选择本周最强的切入角度，用我的语气起草新闻通讯，按参与度层级分段列表，并通过Kit API安排发送——全程无需我打开编辑器。我查看渲染预览并点击批准。困难的创意工作是我的；机械执行是代理的。 **[运营者阅读]** 一个持续发送的新闻通讯胜过那个"更好"但靠灵感驱动才发的。制约因素是执行开销，不是创意。我有想法；我没有每周格式化、安排和分段它们的带宽。代理消除了这个差距。 ## 大多数新闻通讯工作流中真正的瓶颈 大多数新闻通讯自动化建议关注错误的事情：欢迎序列、自动化、标签逻辑。这些都很好，但解决不了每周的创建问题。 真正的阻碍是：你知道想说什么，但坐下来格式化、写主题行变体、选择合适的受众段、在正确时间安排发送，每周需要2-3小时的上下文切换。乘以52周，你已经花了整整一周只是在*发送*新闻通讯。 代理处理"我知道本周的角度是什么"之后的每个步骤。 ## 我使用的技术栈 - **[Kit](/recommends/convertkit)**（前身为ConvertKit）——电子邮件平台。出色的API、稳固的订阅者标签、清晰的分析。代理友好的API是让我选择它的原因。 - **Claude (Anthropic SDK)**——生成层 - **Cloudflare Workers**——定时触发器（每周二上午8点CT运行） - **Airtable**——内容队列和审批收件箱 如果你不在Kit上，相同的模式适用于任何有REST API可以创建和安排广播的平台。 ## 第一步：内容队列 代理需要一个关于"我们在写什么"的真实来源。我的是一个[Airtable](/recommends/airtable)表，包含以下列： - `Topic`——角度或问题 - `Status`——Queue / Approved / Sent - `Tier`——是否面向所有订阅者或仅限高参与度订阅者 - `Notes`——任何约束（避免这种语气、包含这个链接等） 每周，我花10分钟在队列中添加2-3个主题。这是我的创意输入。其余的是代理的工作。 ## 第二步：起草代理 ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## 第三步：审批步骤 代理在Kit的草稿状态下创建广播，并将Airtable记录标记为"Approved"。Kit向我发送带有预览链接的通知。我点击它，阅读，如果看起来没问题，我确认发送。如果我想要更改，直接在Kit中编辑。 这是防止代理在外发邮件上完全自主的关卡。我信任草稿大约90%的时间。审查中发现的10%——语气稍微不对、我想验证的统计数据、想添加的链接——值得那3分钟的审查。 ## 代理处理的我再也不想做的事 - 编写主题行变体并选择最佳的 - 格式化预标题文本 - 计算正确的发送时间（我的受众在周四早上打开；代理知道这一点） - 根据主题层级正确分段 - 将所有内容记录到Airtable以保留记录 ## 我仍然拥有的 *想法*。队列中的主题是我的。角度是我的。代理是清晰简报的出色执行者；它不是战略层。如果我把一个糟糕的主题放入队列，我会得到一封关于糟糕主题的写得很好的新闻通讯。 还有：第一次审查关卡。每一次发送在发出之前都会经过我的眼睛。这不会改变。 ## 运营者的底线 如果你每周花超过一个小时在新闻通讯机制上——格式化、安排、分段——你应该自动化它。Kit API很干净，Worker cron触发器稳如磐石，Claude草稿质量足够高，让我可以批准约90%的第一稿而不作修改。在Airtable中建立队列，连接Worker，然后回归创造想法而不是执行发送。 --- ## 如何在AI搜索中排名，无需撰写任何新博文 Source: https://alejandrorioja.com/zh/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: AI引擎引用直接回答问题、声明清晰作者身份、以便于检索的方式构建知识的内容。大多数现有博文可以通过编辑（而非重写）来满足这三个标准。方案：添加直接的TL;DR、强化实体信号、添加FAQ架构、提交到llms.txt。新内容是可选的；重组不是。 ## 目录 _2026年6月更新。_ **TL;DR：** AI引擎引用直接回答问题、声明清晰作者身份、以便于检索的方式构建知识的内容。大多数现有博文可以通过编辑（而非重写）来满足这三个标准。方案：添加直接的TL;DR、强化实体信号、添加FAQ架构、提交到llms.txt。新内容是可选的；重组不是。 **【运营者视角】** 在撰写第一篇新的GEO定向文章之前，我对341篇现有文章执行了这个流程。ChatGPT和Perplexity中的引用增加了。新内容加速了收益——但从现有内容审计开始，比预期更快地得到了回报。 ## 为什么AI引擎不引用你现有的内容 在写任何新内容之前，先问：为什么我已有的内容没有被引用？ 答案几乎从来都不是"内容不存在"。通常是以下之一： 1. **顶部没有直接答案** — 文章把答案埋在第6段 2. **作者信号薄弱** — 没有清晰的作者实体，内容中没有证书 3. **结构噪音** — 长篇介绍、无关章节、没有清晰的标题层次 4. **没有机器可读的问答** — AI引擎喜欢结构化的问答对；大多数博文没有 5. **不在任何AI可读索引中** — 没有llms.txt，没有爬虫能找到的站点地图 这五个问题都可以在现有内容上修复。没有一个需要新文章。 ## 四步改造流程 ### 第一步：在前100个字中添加直接的TL;DR AI引擎做的事与你浏览时做的类似——在深入之前寻找直接答案。如果你的文章以故事、问题或背景介绍开头，模型可能永远不会读得足够深来找到你的实际答案。 解决方案：在前100个字中添加 **TL;DR** 块。格式：结论 → 原因 → 限制或注意事项。两到四句话。不要废话。 改前示例： > *你有没有想过为什么有些企业似乎主导了谷歌搜索结果？在这篇文章中，我们将探讨排名最高的网站所使用的策略……* 改后示例： > **TL;DR：** 2026年推动本地SEO的三件事：Google商业档案完整性、目录引用一致性以及NAP数据的结构化架构。"每天发布"和"快速获得100条评论"等策略相对于这三点是次要的。上限是你GBP的准确性——先修复那个。 改写后不更长。只是内容前置了。 ### 第二步：强化实体信号 AI引擎构建知识图谱。他们想知道：谁写了这个、关于什么，作者在这个话题上是否可信？ 对于作者实体：确保你的关于页面从每篇文章链接，你的作者架构包含指向LinkedIn和Twitter的`sameAs`链接，每篇文章的作者简介提到具体证书（不是"营销专业人士"——"为三家SaaS公司从0运营SEO到每月100K访客"）。 对于主题实体：使用你受众搜索的精确术语。如果你在介绍"GEO"（生成引擎优化），请在某处说出"生成引擎优化"，而不只是缩写。模型使用术语共现来分类内容。 ### 第三步：为每篇回答问题的文章添加FAQ架构 FAQPage架构是GEO引用中杠杆最高的架构类型，因为它以模型可以直接解析的格式明确地将问题映射到答案。 取出你的文章隐式回答的3-5个问题，使它们明确： ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` 将其添加到文章的``或通过CMS的架构字段。每个主要AI引擎都会爬取并解析这个。 ### 第四步：提交到llms.txt和平台的AI索引 `llms.txt`是一个新兴标准——位于`yoursite.com/llms.txt`的纯文本文件，告诉AI爬虫哪些内容质量高以及如何优先排序。它类似于`robots.txt`但面向LLM。 基础llms.txt： ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` 结合包含`lastmod`时间戳的干净站点地图。AI爬虫会降低看起来过时的内容的优先级。 ## 如何优先选择哪些文章进行改造 并非每篇文章都值得改造。将第一轮重点放在： 1. **已经在问题格式关键词中排名第1页的文章** — 这些最接近被引用；它们只需要结构修复 2. **关于你有可验证公信力的主题的文章** — AI引擎非常重视作者身份；你的证书相关的文章从实体信号获得引用提升 3. **直接回答问题的文章vs提供信息的文章** — "如何做X"和"什么是X"比列表文章或观点文章改造效果更好 使用你的Search Console数据：过滤问题格式的查询（如何、什么、为什么、最好的方法）。排名5–15位的文章是你最好的改造候选——它们相关但还不够接近顶部被引用。 ## 大多数人犯的错误 他们在改造现有文章档案之前就为AI搜索写了新优化文章。新内容有帮助，但现有文章有年龄、反向链接和爬取历史的优势。一篇结构良好的三年老文章会在同一主题上几个月内超越新文章。 先做改造。在有真正缺口的地方写新内容——你现有文章根本没有回答的问题。这才是新胜过旧的时候。 ## 运营者的最终结论 如果你有超过20篇现有博文，你的GEO工作从审计和改造开始，而不是内容日历。在你的前20篇文章上添加TL;DR、强化实体信号、添加FAQ架构并提交到llms.txt，然后再写任何新内容。你会在数周而非数月内看到引用改善——并且你会有更清晰的基准来衡量新内容是否真正推动了指标。 --- ## 我构建了一个运行 Facebook 广告的 Claude 技能——这是代码 Source: https://alejandrorioja.com/zh/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: 我构建了一个 Claude 技能，通过 Graph API 读取我的 Meta Ads 账户，识别低效广告，以我的品牌语调重写广告文案，并创建新的广告集——所有这些无需我打开广告管理器。整个项目不超过 300 行 TypeScript。回报是立竿见影的：我将每周广告管理时间从约 3 小时缩短到约 20 分钟。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 我构建了一个 Claude 技能，通过 Graph API 读取我的 Meta Ads 账户，识别低效广告，以我的品牌语调重写广告文案，并创建新的广告集——所有这些无需我打开广告管理器。整个项目不超过 300 行 TypeScript。回报是立竿见影的：我将每周广告管理时间从约 3 小时缩短到约 20 分钟。 **[运营者视角]** 我为 Pickleland 和我的咨询品牌投放广告。两个账户，不同受众，持续的创意疲劳。我曾将周日下午花在广告管理器里做本该由模型完成的工作。于是我将其自动化了。 ## 为什么我停止手动管理 Facebook 广告 运营 Facebook 广告的实际工作分为三项任务： 1. **监控** — 检查哪些广告集在烧钱，哪些在赚钱 2. **诊断** — 弄清楚*为什么*某个广告效果不佳（创意疲劳？定向不准？落地页问题？） 3. **迭代** — 撰写新文案，创建新广告集，调整预算 任务 1 是机械性的。任务 3 大部分是机械性的（有语调约束）。任务 2 需要判断力——也是唯一需要人工介入的环节。 Claude 技能可以完成 1 和 3。在任何内容发布前，我会审核任务 2 的输出。这就是我最终确定的架构。 ## Meta Graph API 设置（这是烦人的部分） 在写任何代码之前：你需要一个 Meta Business 账户、一个系统用户和一个永久访问令牌。Facebook 的开发者门户体验不佳，但流程如下： 1. 在 developers.facebook.com 创建 **Meta App**（类型：Business） 2. 添加 **Marketing API** 产品 3. 在你的业务组合 → 设置 → 用户 → 系统用户下，创建一个系统用户，并赋予其在广告账户上的 `ADVERTISER` 角色 4. 生成具有以下权限的令牌：`ads_read`、`ads_management`、`business_management` 将令牌存储为 `META_ACCESS_TOKEN`，将广告账户 ID（格式：`act_XXXXXXXX`）存储为 `META_AD_ACCOUNT_ID`，写入 `.env` 文件。 ## 技能文件结构 ``` .claude/skills/fb-ads/ SKILL.md ← Claude 读取的指令 index.ts ← 实际的工具实现 types.ts ← 共享类型 ``` `SKILL.md` 告诉 Claude 何时以及如何使用该技能。我的文件内容如下： ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` "永不自动激活"的约束是不可协商的。该技能以暂停状态创建内容。我手动审核并激活。任何涉及实时广告支出的操作都需要人工检查点。 ## TypeScript 核心代码 （代码块保留英文——仅翻译周围的文字。） ## 日常使用方式 该技能从 Claude Code（我的日常工具）中调用。典型的周一早晨工作流： ``` > check my ads from the last 7 days ``` Claude 运行 `runAdsReport(7)`，将结果格式化为表格，标记低效广告，并询问是否需要重写文案。我说是。它生成新文案，并排显示两个版本，然后以新创意创建暂停状态的广告集。我在广告管理器中审核，激活喜欢的，归档失败的。 总耗时：20 分钟。告别周日下午的广告管理器时光。 ## 这无法替代的部分 该技能无法判断产品与市场契合度问题是否伪装成了文案问题。如果 ROAS 普遍糟糕，那是漏斗或产品本身的问题，而不是标题的问题。Claude 会忠实地在破损漏斗上重写文案——但重写无法拯救它。 诊断步骤仍然是我的职责。我阅读报告，查看漏斗数据，然后决定我们是在迭代创意，还是解决更上游的问题。代理在一切事务上都很快，*唯独*这个判断除外。 ## 运营者的结论 如果你在手动管理广告，每周打开广告管理器超过两次，那你在做脚本本该做的运营工作。Graph API 有完善的文档，Meta 的权限流程虽然烦琐，但只需配置一次。用一个下午构建这个技能。第一周就能看到时间回报。 --- ## 我实际用来运营业务的5款AI工具（2026年） Source: https://alejandrorioja.com/zh/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: 五款工具：Claude（运营者层+编程）、Cursor（TypeScript开发）、Airtable（所有代理的数据骨干）、Kit（通讯+邮件自动化）和Cloudflare Workers（代理托管）。我尝试过的其他所有工具都被这些之一所取代或完全淘汰。如果今天必须重新开始，这就是我会重建的技术栈。 ## 目录 _2026年6月更新。_ **TL;DR：** 五款工具：Claude（运营者层+编程）、Cursor（TypeScript开发）、[Airtable](/recommends/airtable)（所有代理的数据骨干）、[Kit](/recommends/convertkit)（通讯+邮件自动化）和Cloudflare Workers（代理托管）。我尝试过的其他所有工具都被这些之一所取代或完全淘汰。如果今天必须重新开始，这就是我会重建的技术栈。 **【运营者视角】** 我经营两个业务：个人AI咨询品牌（alejandrorioja.com）和Pickleland——位于德克萨斯州普鲁格维尔的匹克球场馆。不同的背景、不同的受众、不同的运营。这五款工具驱动着两者。我列出它们不是因为它们流行；我列出它们是因为我已经删除了它们的替代品。 ## 1. Claude — 运营者层 Claude（通过Claude Code和Anthropic SDK）是一切运转的大脑。我以三种模式使用它： **Claude Code** 是我的日常开发工具。我编写TypeScript、构建代理、调试基础设施问题和管理内容——全部通过Claude Code界面完成。它不仅仅是自动补全；它是一个可以阅读500行文件、理解意图并提出我未曾考虑的重构方案的协作者。 **Anthropic SDK** 驱动着我构建的每一个代理。我的通讯代理、Facebook广告技能、内容流水线、OG卡片生成器——后端全部是Claude。模型质量足够高，约85%的时间我信任第一稿。 **Claude的语音和品牌**判断力被低估了。当我写需要听起来像我的内容时，我发现Claude加上详细的系统提示词优于我测试过的所有其他模型。诀窍是一个具体的、有观点的系统提示词——不是"用随意的语气写"，而是"像Alejandro一样写：直接、实践者视角、无炒作、编号、第一人称、带诚实的注意事项。" 我支付Claude Max费用。这是我使用最多的订阅，ROI无可比拟。 ## 2. Cursor — TypeScript在此编写 Cursor是IDE。大约一年前我从VS Code切换过来，没有回头。 Tab补全足够快，真正改变了我编写代码的方式——我在更高层次思考，让Cursor处理语法样板代码。AI建议的差异视图很清晰。多文件上下文窗口意味着我可以要求它更新一个函数，它也会更新调用者。 我不用Cursor做架构决策。我仍然在纸上或Claude中草拟这些。但一旦设计清晰，Cursor是从设计到运行TypeScript最快的路径。 最大突破：Cursor + Claude Code并行使用。我用Claude Code进行高层规划和代理编排；用Cursor进行具体的实现细节工作。它们不冲突——覆盖不同的层次。 ## 3. Airtable — 数据骨干 我运行的每个AI代理都需要一个读写的地方。那个地方是[Airtable](/recommends/airtable)。 以下是我在两个业务中使用它的方式： - **内容队列** — 进行中的文章和通讯主题，带状态跟踪 - **预订记录** — 从预订系统同步的Pickleland场地预订 - **联盟链接目录** — 105+个含元数据的slug，内容代理在生成时读取 - **代理审计日志** — 运行了什么、何时运行、产出了什么、任何错误 API清晰快速。Airtable不是高吞吐量工作负载的数据库——但对于代理辅助表、审查队列和人工审批工作流，它恰好是正确的工具。可视化界面意味着我可以在不写查询的情况下检查任何表。 我尝试过的替代方案：Notion数据库。Notion API较慢，数据模型对代理读取来说更笨拙。Airtable在代理相邻数据方面获胜。 ## 4. Kit — 通讯和邮件自动化 我切换到[Kit](/recommends/convertkit)（前身为ConvertKit）只有一个原因：API真的很好。 大多数邮件平台将API视为事后想法。Kit将其视为一流产品。我可以创建广播、安排发送、按标签分段并读取分析——全部以编程方式完成。我的通讯代理不需要我触碰编辑器就能完成所有这些。 我使用的Kit特定功能： - **广播API** — 我的代理每周以编程方式创建计划广播 - **订阅者标记** — 我按行为标记订阅者（打开了最近5次发送="活跃"；60天未打开="有风险"），代理相应地定向到各个细分群体 - **表单+着陆页** — 干净、快速加载、无代码。我不以编程方式操作这些；它们就是好用。 如果你在Mailchimp或遗留平台上：迁移值得。Mailchimp的API需要三个额外调用来完成Kit一次调用就能做到的事。 ## 5. Cloudflare Workers — 代理居住的地方 每个计划代理都在Cloudflare Workers上运行。理由：全球边缘部署、免费层零冷启动，以及一个真正有效的cron触发系统。 我的代理不需要服务器。它们需要一个可靠运行、能够进行外部API调用、在我的规模下成本接近零的计划函数。Workers就是答案。 我在Workers上运行的内容： - **内容流水线** — 生成英文文章，分发到12种翻译，生成OG卡片 - **通讯代理** — 起草并安排每周发送 - **Facebook广告监控器** — 读取性能、标记表现不佳者、通知我 - **Pickleland入住率报告器** — 读取预订数据，给我发送每日摘要 所有这些的每月总费用：约$5。这是付费Workers计划。代理按cron计划可靠运行；六个月内我遇到一次故障（Meta方面的DNS问题，不是我这边的）。 ## 我删减了什么以及原因 **Zapier** — 被Workers + 各平台API直接替代。Zapier增加延迟，规模化成本更高，有一个Workers没有的上限。 **ChatGPT** — Claude的上下文窗口、工具使用和系统提示词质量对运营者用例更好。我保留一个ChatGPT标签页用于快速网络搜索，但不在其上构建。 **Webflow** — 将网站迁移到Astro + Cloudflare Pages。更多控制、更好性能、可以脚本化的构建流程。 **Grammarly** — Claude做Grammarly所做的一切，而且更好地保持了我的声音。 ## 运营者的最终结论 上面五款工具不是最新的，也不是讨论最多的。它们是在两个不同业务中经受住日常生产使用考验的工具。在向技术栈添加新工具之前，问自己：这五款中哪一款能做这个工作？你会惊讶于"它们中有一款已经可以"这个答案出现的频率。 --- ## 为什么你的AI代理在生产环境中持续失败（以及如何修复） Source: https://alejandrorioja.com/zh/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: 大多数生产代理失败来自五个原因：无法处理边缘情况的脆弱提示词、缺少瞬态API错误的重试逻辑、无法看到故障的可观察性缺失、没有退出条件的失控循环，以及足够模糊使模型选错的工具定义。五个问题都可以在不更换模型或框架的情况下修复。 ## 目录 _2026年6月更新。_ **TL;DR：** 大多数生产代理失败来自五个原因：无法处理边缘情况的脆弱提示词、缺少瞬态API错误的重试逻辑、无法看到故障的可观察性缺失、没有退出条件的失控循环，以及足够模糊使模型选错的工具定义。五个问题都可以在不更换模型或框架的情况下修复。 **【运营者视角】** 我在生产中运行了30多个代理。我经历过所有这些失败。那些浪费时间最多的不是那些奇特的问题——而是我以为已经处理好的无聊基础设施故障。 ## 失败1：在边缘情况输入上崩溃的脆弱提示词 在测试用例上有效的提示词会在你未预料的输入上失败。这不是模型限制——这是指令编写问题。 **症状：** 代理产生无意义输出、调用错误工具，或在输入与测试内容略有不同时输出格式错误的JSON。 **根本原因：** 你的系统提示词只描述了快乐路径。它没有告诉模型当数据缺失、格式错误或模糊时该做什么。 **修复：** 在系统提示词中添加明确的边缘情况处理： ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` 模型可靠地遵循边缘情况的明确指令。错误在于假设它会将快乐路径指令推广到处理混乱情况。 ## 失败2：瞬态API错误的重试逻辑缺失 你的代理调用的每个外部API最终都会失败。Claude API、Meta Graph API、你的数据库——它们都会返回5xx错误、超时或限流。如果代理没有重试逻辑，一个瞬态错误就会终止整个运行。 **症状：** 代理运行在不同步骤随机失败。日志显示503或429，没有后续尝试。 **修复：** 用指数退避重试包装每个外部调用： ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` 三次指数退避重试处理约99%的瞬态失败。将此添加到每个外部调用，你的一半随机失败会消失。 ## 失败3：无可观察性——你看不到什么在崩溃 这是生产中最常见的失败模式，也是调试成本最高的：代理静默失败或产生错误输出，你不知道链条中哪里出了问题。 **症状：** 你知道有问题但无法确定步骤。你添加`console.log`语句并手动重新运行尝试复现。 **修复：** 每个步骤的结构化日志记录，带有追踪整个执行的运行ID： ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` 如果你在Cloudflare Workers上，这些日志会进入Logpush或Workers Tail。本地运行或VPS上，将其传输到日志聚合器。结构化JSON意味着你可以按`runId`过滤，看到单次运行中发生的确切情况。 ## 失败4：没有退出条件的失控循环 代理循环——模型调用工具并迭代直到满足条件——如果条件从未满足或模型错误识别它，可能永远运行下去。 **症状：** 代理在超时前花费数百美元的API费用。或者它一遍又一遍地运行相同的工具调用而不取得任何进展。 **修复：** 始终设置硬性迭代上限和进度检查： ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` 这捕获了"运行太长"和"原地打转"两种失败模式。上限应该对快乐路径足够宽松，但足够紧以限制爆炸半径。 ## 失败5：模型错误解析的模糊工具定义 如果给模型两个描述重叠的工具，它有时会调用错误的那个。这在`search_database`与`get_record`或`send_email`与`create_draft`等工具中尤为常见。 **症状：** 模型调用了正确类别的工具，但选了错误的具体工具。或者在错误的上下文中调用工具（在只应读取时使用写入工具）。 **修复：** 使工具描述互斥，并明确添加"何时不要使用"： ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` "当X时不要使用"条款是大多数人跳过的部分。这是最重要的部分。模型比从正面描述中推断更擅长遵循明确的负面约束。 ## 还有一件事：在糟糕的输入上测试代理 大多数代理只在干净的快乐路径输入上测试。生产环境有脏输入：空字符串、null字段、Unicode边缘情况、返回200但响应模式意外的API。 添加明确测试以下内容的测试套件： - 空或null输入 - 最大预期长度的输入 - 含特殊字符或非ASCII文本的输入 - 外部API返回意外响应形式 如果你的代理在任何这些情况下崩溃，在上线前修复它。生产环境会找到你做的每一个假设。 ## 运营者的最终结论 大多数生产代理失败是伪装成模型问题的基础设施问题。在切换模型之前，向提示词添加重试、结构化日志记录、循环上限和明确的边缘情况处理。修复模糊的工具定义。然后在糟糕的输入上测试。在责怪模型之前做所有这些——以我的经验，模型通常是最后需要改变的东西。 --- ## 如何在15分钟内构建你的第一个AI智能体 Source: https://alejandrorioja.com/zh/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: 你不需要框架、课程或博士学位。你需要的是Node.js、Anthropic SDK，以及25行TypeScript。本教程将构建一个真实可用的智能体——一个结构化内容摘要器，你可以在同一次会话中将它部署到Cloudflare。唯一的前提条件是一个免费的API密钥。 ## 目录 _2026年6月更新。_ **TL;DR：** 你不需要框架、课程或博士学位。你需要的是Node.js、Anthropic SDK，以及25行TypeScript。本教程将构建一个真实可用的智能体——一个结构化内容摘要器，你可以在同一次会话中将它部署到Cloudflare。唯一的前提条件是一个免费的API密钥。 **[运营者视角]** 我从想用AI做自动化的创始人那里最常听到的一句话是"我得先多学一些"。其实不必。智能体的模式很简单，而理解它最快的方式就是亲手做一个。下面是如果我今天从零开始会走的确切路径。 ## 为什么大多数"构建AI智能体"教程帮不到你 它们要么使用Python（对ML工程师没问题，但对其他所有人都是阻力），要么把真正的代码藏在LangChain之类的框架背后，要么构建出过于抽象、无法与你的实际工作相连的东西。 本教程在三个方面有所不同： 1. **仅用TypeScript** —— 如果你写过JavaScript，就能跟上这篇教程 2. **不用框架** —— 你将看到每一行接触模型的代码 3. **有用的输出** —— 你将构建一个结构化摘要器，可以真正用在客户邮件、评论或会议记录上 ## 你将构建什么 一个**内容摘要智能体**：粘贴任意一段文本，返回格式一致的结构化摘要。一个HTTP请求进，一份干净的摘要出。 为什么把它作为第一个项目：这个模式——系统提示 + 用户输入 → 结构化输出——是我运行的每一个智能体的基础。替换系统提示，你就得到一个问答器、一个语气改写器、一个分类器或一个草稿生成器。学会这一次，你就掌握了生产环境智能体实际工作内容的80%。 ## 前提条件（2分钟） - **Node.js 18+** —— 用`node --version`检查。如有需要，从nodejs.org安装。 - **一个Anthropic API密钥** —— 在[Claude](/recommends/claude)注册，从控制台获取一个密钥。免费额度即可。 - 一个终端和一个文本编辑器。 不用Docker。不用虚拟环境。不用`pip install`任何东西。 ## 第1步：创建项目（2分钟） ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` 在`package.json`中添加一个脚本，以便轻松运行智能体： ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## 第2步：编写智能体（5分钟） 创建`agent.ts`并粘贴以下内容： ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## 第3步：运行它（1分钟） ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` 预期输出： ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` 这就是一个可用的AI智能体。真实输入、自定义系统提示、结构化输出。整个东西只有30行代码。 ## 第4步：根据你的使用场景进行定制 系统提示是让这个智能体成为你专属智能体的唯一要素。下面是三个可以直接替换使用的方案： **客户评论分类器：** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: