Agent

翻看十月九日仍在更新的 Claude 平台 release notes，Agent Skills 和对应的 Skills API（/v1/skills）已经正式离开测试版状态：请求里不再需要带 skills-2025-10-02 这个测试头，就连 Messages API 里通过 container 参数加载 Skill 的调用也转正了。同时，那个 BetaSkill 类型被重命名为 BetaContainerSkill，旧头还能兼容一阵子。对 Agent 框架的开发者来说，这不是一次小版本——它意味着「给模型外挂一套随取随用的专业工具包」这件事，从临时实验变成了一等 API。 Skills 到底是个什么东西，和 MCP 工具差在哪？ MCP 解决的是「让模型能调用外部工具」：连数据库、调 API、跑脚本，重点在动作。Skills 解决的是「让模型临时获得某项专业知识与流程」：它是一组说明、脚本和资源的打包，模型在做某个专门任务时动态加载进来，干完就卸载。区别在于，MCP 是接外部世界的手，Skills 是塞给模型的一本「临时操作手册」。比如做一个财务审计的 Skill，里面放着审计清单、勾稽脚本、报表模板，模型遇到审计任务时自动把这套东西读进去，而不是把所有领域知识都塞进系统提示词里。 容器化加载，解决了之前的什么痛点？ 早期 Skills 要靠测试头和一堆 beta 结构硬挂，加载方式是隐式的。现在转正后，Skills 通过 container 参数以容器化方式加载，配合 client.beta.skills.delete() 这类接口，可以完整管理一个 Skill 的多版本、动态增删。这等于给「模型的专业能力包」建立了生命周期管理：谁在用哪个版本、什么时候加载、什么时候卸载，都变成可显式控制的对象。对企业来说，这才是能上生产的形态——能力包可以像 App 一样上架、灰度、回滚，而不是散落在提示词里的魔法字符串。 这对 Agent 开发生态意味着什么？ Skills 转正加上容器化，等于官方在推一种新的分发单元：以后模型的能力不再只靠微调权重，而是靠一摞可组合、可热插拔的 Skill。你想让 Claude 会做某个垂直任务，不必重训模型，只需发一个 Skill 包。这会催生一个类似 App Store 的 Skill 生态——谁写的 Skill 更专业、加载更省 token，谁就更有价值。对框架作者，接下来要关注的是 Skill 之间如何复用、版本如何治理、以及一个 Skill 在被自动加载时会不会带入新的提示注入面。能力包越自由，供应链风险就越要盯紧。 ...

据 AI Tool Tier 评测数据，Cognition 的 Devin Fusion 采用 lead/sidekick 双模型编排架构，实测每个编码任务的成本比单一大模型方案降低百分之二十三到四十六。这个架构跟传统的单 Agent 循环思路完全不同。 分工是这样的：lead 模型负责理解任务、拆解步骤、审查 sidekick 的输出；sidekick 模型负责实际写代码、跑测试、改文件。lead 用强模型但调用次数少，sidekick 用便宜快速的模型但承担大部分 token 消耗。两模型通过结构化消息通信，不是简单的提示词嵌套。 这种编排的经济学很直观：大模型贵但你不需要它全程参与——只需要在关键决策点用它。执行层面的重复劳动交给小模型。九月十五日 Cognition 跟 AWS 签了多年期协议，把这个架构跑在 AWS 基础设施上，说明成本优化已经到了可以规模化的阶段。 Devin Fusion 的双模型架构给整个编码 Agent 行业提供了一个新的思路。以前大家都在追求一个超大模型包打天下，Fusion 证明了用两个各司其职的模型组合起来，效果更好还更便宜。这个思路很可能会被其他编码 Agent 产品借鉴。 从成本结构上分析，lead 模型虽然单价高但调用次数少，sidekick 模型单价低但承担大部分 token。这种组合的总成本比全程用大模型低百分之二十到四十六，这个数字在规模化之后是非常可观的节省。对于每天处理成百上千个编码任务的团队，每省一块钱乘以任务量就是大钱。 为什么两个模型比一个大模型更省钱？ 这个思路其实跟人类团队的分工一样：架构师不用亲自写每一行代码，但要审查每个关键决策。初级工程师写大部分代码，但每个 PR 都要过架构师这关。Devin Fusion 把这个模式复制到了 AI Agent 里。 lead 和 sidekick 具体怎么分工？ 对自建编码 Agent 的团队来说，这个架构值得借鉴。你不一定需要用 Devin，但可以用同样的思路：用一个强模型做路由和审查，用便宜模型做执行。这种分层可以显著降低每次编码任务的边际成本。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 Cline 项目 README，这个开源编码 Agent 的命令行工具提供四种运行模式。默认的 cline 或 cline -i 打开完整终端交互界面，带 plan/act 切换、斜杠命令、文件提及和实时工具审批——适合人在旁边盯着的交互式编码。 cline 直接加 prompt 参数则是一次性模式：跑一个回合就退出，适合脚本里调用。cline –json 模式以 NDJSON 格式流式输出事件，可以管道接进其他工具或 CI 系统——你可以自己解析事件流，在工具执行前加自定义审批逻辑。 最激进的是 cline –yolo 模式：跳过所有审批提示，让代理自主执行直到任务完成。这个模式威力巨大但风险也大——它会自己改文件、跑命令、装依赖。建议只在隔离的 Docker 容器或临时分支里用，千万别直接在主力开发机上开 Yolo。 Cline 作为开源编码 Agent，最大的优势是透明和可控。跟闭源的 Devin 或者 Claude Code 不同，你可以看到它的每一步操作、修改它的提示词、定制它的工具权限。这种可控性对于有安全合规要求的企业特别重要。 四种运行模式覆盖了从交互式开发到全自动化 CI 的完整场景。TUI 模式适合人在旁边盯着的探索性编码，one-shot 模式适合脚本里的简单任务，JSON 模式适合接入自研的审批流程，Yolo 模式适合在隔离环境里批量处理。选择哪个模式取决于你对自动化程度和风险承受力的平衡。 JSON 事件流模式怎么接入 CI 流水线？ JSON 事件流模式是接入 CI 的关键。你可以写一个脚本启动 cline –json，监听事件流，在代理要执行危险命令时插入人工审批或者自动拒绝。这样就实现了半自动化——代理做大部分工作，关键节点人来把关。 Yolo 模式到底有多危险？ Cline 作为开源项目，跟闭源的 Devin 和 Claude Code 相比，优势在于你可以完全掌控它的行为。所有提示词、工具列表、审批规则都可以自定义。对于有安全合规要求的企业，这种可控性是闭源工具给不了的。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 Mastra 官网更新，十月一日平台新增了 VPC 隔离的托管 Postgres 数据库服务。这不是给普通 Web 应用用的——它是专门给 Mastra Agent 做状态存储的：会话历史、记忆条目、工作流中间状态、工具调用日志，全部持久化在这个 Postgres 里。 VPC 隔离意味着你的数据库跟 Mastra 平台其他用户的数据库在网络层面完全隔离，只能通过你自己的 VPC 连接。对企业用户来说这是合规要求——Agent 处理的数据不能跑在共享多租户环境里。 同期发布的 Server Adapters 则解决了部署痛点：以前你要单独起一个 Mastra 服务端口，现在它可以作为中间件挂在你已有的 Express 或 Hono 应用里。Agent、工作流、工具和 MCP 服务器自动暴露为 HTTP 端点，不需要额外的运维负担。 Agent 应用的状态管理一直是个被低估的难题。跟普通 Web 应用不同，Agent 的状态不是简单的用户数据——它包括对话历史、长期记忆、工作流检查点、工具调用审计。这些数据量很大，而且查询模式很特殊。专门为 Agent 设计的 Postgres 托管服务正在填补这个空白。 Server Adapters 的出现则意味着 Mastra 的部署模型更加灵活。你不再需要单独部署一个 Mastra 服务，而是可以把它作为中间件嵌入现有的 Node.js 应用。对于已经有 Express 或 Hono 后端的团队，这省去了维护额外服务的运维负担。 从产品演进的节奏来看，Mastra 几乎每个月都有重要功能发布，这种迭代速度在开源 Agent 框架里算是很快的。 Agent 为什么需要专用 Postgres？ Agent 应用的状态存储比普通 Web 应用复杂得多。你需要存多轮对话历史、长期记忆向量、工作流的检查点、工具调用的审计日志。用普通 Postgres 也能存，但 schema 设计和查询优化很费时间。Mastra 把这些都做好了。 ...

据 Mastra 官方博客十月七日文章，Mastra Connect 正式发布。它的核心能力是：你的 Mastra Agent 现在可以通过统一的 OAuth 连接管理器，调用 Linear、Notion、Slack 以及另外二十多个 SaaS 服务，不需要为每个服务单独写集成代码。 之前要让 Agent 读 Notion 页面、改 Linear ticket、发 Slack 消息，你得分别去各平台申请 API 凭证、写请求封装、处理 token 刷新。Connect 把这些标准化了——在 Mastra Studio 里点几下完成 OAuth 授权，Agent 代码里直接 import 对应工具就行。 同期发布的还有 VPC 隔离的托管 Postgres 数据库，以及 Server Adapters——让你在已有的 Express 或 Hono 应用里直接挂载 Mastra Agent、工作流和 MCP 服务器作为 HTTP 端点。对 TypeScript 技术栈的团队来说，Mastra 正在从一个 Agent 框架长成完整的 Agent 运行时平台。 Mastra Connect 的发布，本质上是在解决 Agent 开发中最耗时的环节：工具集成。写一个能读 Notion、改 Linear、发 Slack 的 Agent，光写各个平台的 API 封装就要好几天。Connect 把这些标准化之后，开发者可以把精力集中在 Agent 的业务逻辑上，而不是跟各个 SaaS 平台的 OAuth 流程搏斗。 ...

10 月 7 日 OpenAI 推送 GPT-6 Sol 与 GPT-6 Luna 的十月更新，并把「智能界面面向所有人」作为产品化方向。对做 Agent 的团队来说，这两个名字不只是 marketing，而是两条不同推理档位的公开信号。 Sol 与 Luna 到底是两个模型，还是两种思考预算？ 可以把 Sol 理解为深度推理档：允许更长的思维链、更多次自我校验，适合数学、代码、规划这类需要多步推演的任务。Luna 则是快速档：短链路、低延迟、便宜，适合问答、摘要、分类这类「想一下就够」的场景。厂商官方没有公开精确的触发阈值与价差，但从 o 系列以来的惯例看，深度档的 token 消耗往往是快速档的数倍。 路由选错档位，账单会差出多少？ 真正烧钱的不是选了哪个档，而是该用快档时用了深档。一个取邮件、读日程的工具调用，如果默认走 Sol，每一步都在做「长篇思考」，账单会比走 Luna 贵出一截。 务实做法有三条：在系统提示里显式标注任务复杂度；对工具调用类请求强制走快速档；只在规划与调试节点开放深度档。Manus 2.0 靠框架优化把 Token 消耗压下 23.2%，其中相当一部分正是这种「档位选错」的浪费。 双档并行之后，Agent 工程的核心技能变成了什么？ 双档并行会成为 2026 下半年旗舰模型的标配。未来 Agent 工程的核心技能之一，就是给每一步推理标对价格标签——把贵的思考留给真正需要它的那几步。 一个可落地的档位路由策略长什么样？ 把工作流里的每一步按「是否需要多步推演」打标签：取数、读配置、格式化这类动作直接绑定快档；写代码、做规划、排错这类节点开放深度档。更稳的做法是让模型自己先输出一个「复杂度自评」，再由路由层决定送哪一档——这比写死规则灵活，又比让模型自由选择省钱。记得把每一步实际走了哪一档、花了多少 token 记录下来，跑两周后回看，你会发现有相当比例的深度调用其实用快档也能过。把这部分省下来，就是白捡的利润。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：GPT6-Sol-Luna

过去两年我们被两种相反的说法同时轰炸：一种说 AI Agent 马上取代白领工作，办公室要空一半；另一种是 Manus 这样的公司，融资当天就在北京放出一堆岗位，一天收上千份简历。这两件事不可能同时是真的——要么 Agent 已经能自主干活不需要人，要么它还在靠人海战术顶着。到底谁在说谎？仔细看，答案不是某一方撒谎，而是我们把「人」这个角色想简单了。 Agent 到底取代的是动作还是岗位？ 说 Agent 取代白领的人，看的是单个任务：写周报、回邮件、查数据，这些确实正在被 Agent 接管。说 Agent 公司疯狂招人的人，看的是整个系统：一个 Agent 要跑得起来，得有人设计任务、有人写工具描述、有人在出错时兜底、有人对着真实业务调工作流。 一个白领过去每天做十件重复的事，现在这十件事里八件被 Agent 干了，剩下两件是「判断这件事该不该让 Agent 干、以及干砸了怎么办」。他的岗位没有消失，而是从「干活的人」变成了「管 Agent 的人」。Manus 招的上千份简历，招的就是这种新岗位。 哪一头被高估、哪一头被低估了？ 公众的焦虑来自一个错误等式：Agent 能做某件事 = Agent 能独立做完整件事。现实是，从「能做」到「能在真实混乱环境里做完做对」，中间隔着大量人的监督。今天的 Agent 还处在「需要人牵着走」的阶段，不是「自己跑完一整个流程」的阶段。 所以现在就业市场的真实图景是：纯执行类岗位在收缩，但「Agent 监理」类岗位在膨胀。总量上未必少了多少人，但对人的要求变了——不再是要你手快，而是要你会拆任务、会纠错、会定义什么算对。Manus 一天上千份简历，正是大量人本能地嗅到了这个转向。 什么时候才算 Agent 真的替代人？ 真正的临界点，不是 Agent 能写周报，而是 Agent 公司自己停止招人。当 Manus 这类公司不再需要上千人来打磨工作流、不再需要人在后面兜底，那才说明 Agent 真的可以无人化。现在它还在疯狂招人，恰恰是最强的反证。 别被两头的叙事吓到。喊替代的，卖的是焦虑；抢人的，给的是机会。看懂这个矛盾的人，已经在往「管 Agent」的方向转身了。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Agent与就业

Agent 产品和聊天机器人最大的区别，是它替用户把事办完了。既然办完了一整件事，按 token 收费就显得荒谬——用户不关心你烧了多少 token，只关心事有没有成。业界已经开始出现「按任务/按结果收费」的模式，Manus 这类通用 Agent 本质就在往这个方向走。但按结果收费听起来性感，落到合同里全是坑。本文把必须写死的三件事讲清楚。 第一件事：到底什么才算任务「完成」？ 按结果收费的死穴，是双方对「成了」的理解不一致。用户说「帮我订一张去上海的机票」，Agent 订了一张早班机——这算成了吗？用户想要下午的，Agent 说任务状态是成功。如果合同里不定义完成标准，这种纠纷每天都会发生。 正确做法是把完成标准写成可机器判定的条件：是否出票成功、航班时间窗、是否满足预算上限。满足全部条件才算计费，缺一条都退单重跑。VulcanBench 那类按任务统计成本的方法，本质就是在做这件事——把「成没成」量化。 第二件事：任务失败的成本算谁的？ Agent 跑失败是常态，不是意外。问题是：跑失败烧掉的 token 成本，算谁的？如果算用户的，用户跑十次失败九次，账单比成了还贵，立刻弃用；如果算你的，一个死循环任务能把你烧穿。 合同里必须写：失败任务不计费，但设一个重试上限（比如三次）。超过三次还没成，双方一起排查，不再单方面烧钱。这个上限就是你成本的保险丝。 第三件事：什么事不归 Agent 管，边界在哪？ 按结果收费最大的风险是「结果范围无限大」。用户说「帮我把这个季度的报表搞定」，Agent 到底是只拉数据，还是要写分析、要发邮件、要通知领导？范围不清，你就是在签一份开口合同。 合同里要列清楚：包含哪几步、不包含哪几步、需要用户人工确认的节点在哪。每多做一步，单独计价。Manus 这种通用 Agent 之所以贵，就是因为它边界模糊——你以为它会自己搞定，结果它卡在每个需要确认的地方等你。 按结果付费到底能不能走通？ 按结果收费是 Agent 商业化的终局方向，但它不是改个价格表那么简单，而是把你的产品重新变成一份可定义、可审计、可限定范围的服务。合同写不清楚的 Agent，定价模式再新潮也会被退款和纠纷拖垮。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：按结果付费

GPT-6 Luna 把输入价打到 0.10 美元每百万 token 之后，做 Agent 产品的人终于敢放开免费额度了。过去不敢放，是因为一个免费用户跑复杂任务一次就能烧掉几毛钱，一千个白嫖用户一天的账单比收的订阅费还多。现在脏活累活可以走便宜模型，免费试用的单位成本被压到一分钱量级，漏斗的第一道闸门终于能开了。问题是，开了之后怎么把白嫖的人筛成付费的。本文给一套埋点设计。 免费额度放多少，成本账怎么算？ 放免费额度之前，先定一个数：你能承受单个免费用户每月花你多少钱。按 Luna 价算，一个用户每天跑 10 次、每次几千 token，月成本大概一两毛钱。这意味着你可以放心地给每个新用户一个「够玩一周」的免费额度，而不担心被薅破产。 这个成本账要先算清楚，再去设计漏斗。成本可控，才敢放水。 转化漏斗该埋哪三层点？ 第一层，注册到首次完成任务。大多数用户注册后第一次任务没跑通就流失了。埋点看「注册后 24 小时内是否成功完成第一个任务」，这个转化率是你产品的生死线。低于 30%，说明 Onboarding 有问题，别忙着拉新。 第二层，免费额度消耗速度。埋点看用户每周用掉多少免费额度。用得快的，是真需求；用得慢的，是好奇心。对用得快的那群人，在额度用到 80% 时弹付费引导，转化最高。 第三层，付费后留存。别只看付费转化，要看付费后第二个月还在不在。很多产品首月转化好看，次月全退，说明免费到付费的引导是靠冲动，不是靠真实价值。 付费墙该放在漏斗的哪个位置？ 免费额度不是越多越好。放太少，用户没体验到核心价值就走；放太多，用户在免费档就把事干完了，没有付费动机。正确做法是：免费档让用户把一个完整小任务跑通，感受到爽点；但把「批量处理」「长任务」「优先速度」这些进阶能力锁在付费墙后。 这正好接上前面说的速度分舱——免费档走慢的标准算力，付费档解锁 Fast。用户为了不等，自然掏钱。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：免费额度漏斗

GPT-6.1 Sol 按速度卖三档这件事，对做产品的人启发远大于对用户的情绪。OpenAI 等于公开演示了一套「延迟分舱」定价法：同一模型，按算力优先级分成标准、Fast、Ultrafast 三档，价格差最高 6 倍。如果你正在做任何带 AI 生成的 SaaS，这套打法今晚就能照搬。本文给一套可落地的设计。 你的产品该不该做「三档」？又该对应什么？ 不是所有产品都该分三档，但只要你的产品里有「等结果」这个环节，就有分舱空间。先把用户的等待场景拆开： 标准档：后台批处理、邮件摘要、夜间跑的报表——用户能等，走最便宜的算力池。 Fast 档：实时对话、客服机器人、文档起草——用户在屏幕前等，需要秒级响应。 极速档：游戏内 NPC、交易信号、直播实时字幕——晚一秒就穿帮。 你会发现，同一套底层模型，在这三个场景下的付费意愿差一个数量级。按一个价格卖，等于把极速场景的高价值白白让给了免费用户。 这套延迟分舱具体该怎么落地？ 第一步，在产品里把「生成」这个动作做成可配置的延迟档位，默认给标准档，付费开关解锁 Fast 和极速。第二步，后端对接模型时做路由：标准档走 Luna 这档便宜模型加队列，Fast 档走 Sol 标准价，极速档走 Ultrafast 并预留算力。第三步，定价上参考 OpenAI 的梯度：标准档含在订阅里，Fast 档加 30% 溢价，极速档按次或按专属配额单独卖。 关键是给极速档设硬配额。如果不设上限，一个高频用户就能把你最贵的算力烧穿。OpenAI 敢卖 6 倍价，就是因为知道极速档的容量是稀缺的。 做分舱定价最容易踩什么坑？ 别把「智能」和「速度」混在一个档位里卖。用户为快付钱，不是为更聪明付钱。如果你的极速档只是排队优先、模型没变，就老实说「加速」；如果极速档偷偷换成了更强模型，那要单独标出来。价格信号一旦和用户预期错位，就是 GPT-6.1 Sol 现在面对的口碑翻车。 分舱定价的本质，是把你过去混在一起卖的「体验」拆成可计量的层。拆得越清楚，愿意为快付钱的人越容易掏钱。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：速度分舱定价