AI圈子首页 · 最新大模型、AI产品、Agent与开源项目动态

Sonnet 5.5 比 Opus 差两分，单任务却贵了五成。

Artificial Analysis 给出的首批评测数字是这样的：Claude Sonnet 5.5 在智能指数上得 56 分，离 Opus 5.5 满档只差 2 分；开到 max effort 后比 Sonnet 5 高出 18 分，直接坐上仅次于 Opus 5.5 的第二把交椅。

定价看着没动，账单却变了样。单价还是每百万 token 输入 $2、输出 $10，和 Sonnet 5 一个价。可它每个任务吐的 token 更多，单任务成本落到 $7.60，比 Sonnet 5 高出约五成。

max effort 下平均每项任务烧掉约 19.3 万输出 token，是各家评测里见过最重的，比 Opus 5.5 高六成，约是 GPT-6 Astra 的七倍。

能力和短板都摆得很直白。终端任务上 Terminal-Bench 4.0 拿 64%，反超 Opus 5.5 和 GPT-6 Astra 的 60%；在 AA-Briefcase、GDPval-AA、AutomationBench-AA 上与 Opus 5.5 打平，代价是用掉多得多的 token。

短板在事实知识，AA-Omniscience 上 54% 对 Opus 的 66%，不过幻觉率更低，47% 对 59%；人类最后考试和 SciCode 也落后约 6 分。

这组数字给我提了个醒：单价没涨不等于成本没涨。省不省钱要看每个任务的总输出，token 吃得猛的模型，便宜的单价会悄悄翻倍。性价比还得看它在智能与单任务成本的前沿上站在哪，评测指出这个价位下 Sonnet 5.5 落在了前沿之外。

保留意见是这次测的是预发布版本，Anthropic 说结构化输出有 bug，公开版已修，正式分数可能还会往上走。等复测出来，这个结论才好下死。

选型的判断可以先立着：要终端和协作打平 Opus 的效果、又愿意为它多付五成 token 的场景，Sonnet 5.5 值得上；预算卡得紧的，同价位下 GPT-6 Sol 或 Astra 的配置反而更划算。等复测一出，我会拿自家任务的输出量重算一遍再定。

一份开源的 agent 配置，把"规则写三遍"这个老大难解掉了。OpenClaw 的创造者 Peter Steinberger 把自己的整套 agent 环境公开，仓库在 github.com/steipete/agent… ，6.6k stars，MIT 协议。

核心动作只有一个：全机器的 agent 都读同一个文件夹。一份 AGENTS.MD 存全部规则，脚本把它符号链接到 Claude Code 的 CLAUDE.md 和 Codex 的 AGENTS.md，两边永远读到同一份指令。

其他仓库顶部只需一行：READ ~/Projects/agent-scripts/AGENTS.MD BEFORE ANYTHING。改一次规则，所有项目同时生效。

Skills 的管理照搬同一套思路。69 个 skill 集中放一处，每个带一段简短描述，agent 靠描述决定加载哪个；再由 sync-skills 脚本把它们链进两个 agent。我见过太多人 skill 散在各个仓库，改一个忘三个，最后哪个版本在生效自己都说不清。

看完我立刻意识到自己踩过的坑。同一个项目里 CLAUDE.md 和 AGENTS.md 写了两遍规则，一边改了另一边忘，模型行为就飘。符号链接这招土得掉渣，却正好治这个病。真正的工程里，能用文件系统解决的就别发明新机制。

先说保留：他的 AGENTS.MD 里塞着他自己的主机和账号，fork 之后第一件事是换成自己的，再把用不上的 skill 删干净。这一步跳过去，等于把自己的密钥摊在每个 agent 面前。

我的动作已经定了：fork 下来，规则替我自己的，技能先留常用的那十几个。跑顺之后再谈加，同一件事我这周已经给自己定了两次节奏，一个个来。

做视频的 Skill 清单我见过不少，这份的分类和安全评级少见地用心。整整 180 个开源 skill，让 Claude、Codex 能直接干视频的活，仓库在 github.com/zhuyansen/awes… 。

六类挑三类说。剪口播有 cut-video，静音和嗯啊自动剪掉；Premiere 那个 MCP 更狠，1027 个工具，agent 在 PR 里就能剪时间线、调色、混音。做宣传片的 video-shotcraft 攒了 152 张镜头配方卡，另有拿产品真实组件出更新片的 skill，画面跟产品对得上。

科普方向给个选题就出纸拼贴讲解视频，Paper-Cut 绕开视频模型，出图后拆层用代码做动画。

别的也在列。CSV 进去图表出来，每帧数字都准。中文故事喂进去出手绘漫画风动画，换成诗或成语出的是国风纸片动画。不露脸的 Shorts 工厂也备好了，画面到字幕整条打通。

让我上心的反而是安全评级。180 个第三方 skill 挨个标风险，等于替我做完第一轮筛选。自己翻 GitHub 挑，最费的就是这步，代码看不完不敢装。

我的打算很克制。先只碰一个类别，拿剪口播跑自己的音频，能用再往宣传片扩。清单越长，越要守着一个个来的节奏。一次装十个，坏一个就全盘怀疑。

记忆系统不是选个向量库就完事，它有六层。

这份路线把 Agent 记忆从头到尾拆开，标题就说清了目标：检索极速、召回忠实、演进安全。我按它的顺序捋一遍，顺带说说我卡在哪层。

第一层管上下文和工作记忆。窗口策略给了四个选法：滑动窗口（Sliding Window / FIFO）简单但会丢早期约束；动态摘要省地方却可能失真；按 token 权重裁剪偏实用；层次化则把核心提示、概要历史、实时输入分开摆。

状态机这节提到 LangGraph 的显式状态，靠结构化变量传递。最讨巧的是 MemGPT 式虚拟内存，借操作系统的主存外存思路，让 agent 自己调用 core_memory_append 这类指令，在有限窗口里做出无限上下文的假象。

第二层是存储引擎。向量库管语义检索，密集向量和稀疏向量（Sparse / BM25）配合混合检索加重排，RAG 应用全靠这层撑；图数据库管关系推理，三元组抽实体和关系，Neo4j、Memgraph、FalkorDB 在列，图检索走 Graph RAG。

PostgreSQL、Redis、SQLite 这类管硬约束和审计日志。单用一种都不够，正解是三种协同，语义、关系、精确属性各归各家。

第三层是我最看重的生命周期：写入、检索、反思、遗忘。检索那节给了公式化的三件套，相关性看余弦相似度，时效按指数衰减，重要性交给模型打分，还有时间感知检索区分先后说过的话。遗忘那节更实用，类 LRU 的淘汰加上 GDPR 被遗忘权，敏感信息 PII 自动脱敏抹除。前面聊过的记忆纠错和时间戳问题，全落在这层。

第四层列了工程件。LangChain、AutoGen、CrewAI 这些框架内置的内存属轻量选法，LangGraph 的 MemorySaver 和 LlamaIndex 的索引式记忆都在此列。认真做就看专用引擎：Mem0 管多级记忆，Zep 自带时序和摘要图谱，Letta 按 OS 理论做内存服务。评估则看召回率、精准率和检索里的幻觉率。

第五层安全隔离，我看得心里一紧。租户隔离必须严，A 的记忆绝不能被 B 召回；还要防投毒，一句注入就能把恶意内容写进记忆；外加 ABAC、RBAC 权限控制和审计日志，得能回答"agent 为什么做这个决定、是哪条记忆引发的"。

第六层才是场景实战，伴侣助理、客服、NPC、编程助手、多 agent 共享黑板，各有一套搭配。路线末尾还顺带比了两条进阶路线，HippoRAG 这类图式检索对上 LoRA 微调，让记忆沉淀进权重还是留在检索侧，得看任务。

我自己的进度停在第三层。存和取早跑通了，冲突判优和定期整理一直没做，图谱里新旧事实打架都没人裁决。下一步我打算先补冲突检测和一次离线整理，把这条链闭上，再去折腾选型。

出站流量这个刺客，Upstash 这次直接给抹了。它给自家对象存储 Upstash Blob 加了条新规：所有计划每月 1TB 出站流量免费，无需申请，全员自动生效，详情在 upstash.com/blog/upstash-b… 。

面向 WebDev 场景的 SaaS 和云存储都爱讲 CloudComputing 的账面故事，这次讲的是省。

账单这东西只有被刺过才懂。对着 AWS S3 算一笔：存几百兆常只要几美分，可外部下载一旦到 1,000 GB，带宽一项约 81 美元。存储和流量的价格差着数量级，而流量藏在读取动作里，等你看见已经晚了。我自己的小项目就在这种账单上吃过亏，当月看到数字才知道读取是要钱的。

这次更新的亮点很明确。1TB 每月的免费出口，够放用户头像、文章附件、应用资产，也够放 AI Agent 自己生成的音视频和图像文件，这类文件恰恰是读取最频繁的一类。免费档在内全套餐都算数。

它还专为现代 Web 栈和 Edge Runtime 设计，配 Next.js 或 Remix 用，省掉了传统 S3 那套 IAM 鉴权、Bucket 策略、单独挂 CDN 的折腾，文档跟下来一分钟能调通读写。

不过我保留一分。免费出站是获客期的好事，一年后政策会不会改、超了 1TB 怎么计费，这些得看长期条款。云厂商的免费额度我从来当试用期看待，不当承诺。

我的打算很简单：把我那个放用户上传图片的小项目迁过去试一个月，盯两件事，一是读取延迟，二是月底账单。迁移成本半天以内，值得换这个安心。

估存储这件老手艺，换到大模型上照样管用。做过后端的人每接一个需求都要算：数据库占多少、缓存占多少、多少并发配多大机器。KV Cache 就是同一件事在推理侧的版本：一条请求占多少，并发一上来会怎样。

公式先摆出来。KV Cache 等于 2 乘层数乘 d_model 乘序列长度乘字节数，那个 2 是 K 和 V 两份。

拿三个量级走一遍就清楚了。先用最小的玩具例子：fp32、2 层、d_model 等于 4，算下来每 token 64 字节，3 个 token 才 192 字节，小到可以忽略。换成 GPT-2 small，12 层、d_model 768、fp16，每 token 约 36 KiB，满 1024 上下文约 36 MiB 一条，还算温和。

真正吓人的是 Llama-2-7B 量级，32 层、d_model 4096、fp16，每 token 512 KiB，4096 上下文就是 2 GiB 一条。同时伺候 16 个用户，光缓存 32 GiB，比一张 24GB 的消费级显卡还大，而这还没算模型权重。

我的判断是这条比很多优化文章都实用。增长来自四个方向：模型侧的层数和 d_model，使用侧的序列长度和并发数。四项两两乘起来，任何一项翻倍都会把显存推着走。你没法改模型，但序列长度和并发握在自己手里。

这也解释了我之前看不懂的两件事。为什么长上下文服务那么贵，为什么高峰期限流。以前我只知道结果，现在能自己把账算出来了。我打算拿手头那套服务按这个公式估一遍，先看并发上限卡在显存的哪个位置。