Anthropic 在 claude.dev 博客中拆解 Claude Code 单个任务的成本构成，指出轮次、缓存读取、输出 token 类型和模型选择四项决定开销。Opus 5.5 的输入与输出价格比 Opus 5 低 20%，缓存读取低 60%，API 列表价为每百万输入 token 4 美元、输出 20 美元、缓存读取 0.20 美元。文章建议先用中等 effort 处理范围明确的任务，给模型可自行验证的手段，把搜索类子智能体放到 Sonnet 或 Haiku，并用 /usage 在自己的任务上实测。
#教程/实践#部署/工程#Anthropic
SemiAnalysis 发布 ClusterMAX 3.0，对 77 家 neocloud 做全面评测，市场覆盖范围从 2.0 版的 209 家扩大到 323 家，并访谈了 200 多名终端用户。Nebius 与 CoreWeave 同列 Platinum，Google Cloud 与 Oracle 进入 Gold，Azure 降至 Silver，Crusoe 降至 Bronze，全球仅 19 家 neocloud 获得奖章评级。评测分审计、性能、可靠性三阶段，涵盖 GPU 计算、网络、存储、编排、监控与故障注入，并新增 Bronze 与 Underperforming 之间的 Participation Ribbon 档。
#行业动态#部署/工程#数据/训练
#开源/仓库#视频#开源生态
Modal 官方工程博客复盘了为编码智能体提供推理服务的优化过程，以 Moonshot AI 的 Kimi K2.6 为例，单副本每用户性能提升 2.8 倍、副本整体提升 5.6 倍。他们用 NVFP4 微缩放格式在 B200 上部署约一万亿参数的模型，基于 SGLang 打补丁并回馈上游，通过 DFlash 投机解码、KV cache 量化与 HiCache 扩展缓存，再配合负载感知的有状态路由，把服务扩展到每天处理数千亿 token。相关代码与配置已作为 Modal Auto Endpoints 的开源后端发布。
#教程/实践#部署/工程#推理
Anthropic 在两周冲刺中把 claude.ai 和 Claude 桌面应用的核心体验提速约 3 倍，75 分位下全新加载的可输入页面从 3.1 秒降到 0.55 秒，新建 Claude Code 会话从 0.8 秒降到 0.3 秒，加载 Claude Cowork 云会话从 2.6 秒降到 0.73 秒。团队用 Claude Tag（beta）在单个 Slack 频道内驱动流程，合并了三千多个改动且没有出现面向客户的事故或回滚。做法上，Claude 通过 Datadog MCP server 分析使用数据，锁定占 95% 用户活动的四条路径，并建立指令计数、React commit、样式重算等可在实验室复现的基准，再以 CI 棘轮和功能开关控制风险。
#行业动态#Agent#部署/工程
Together AI 发布教程，介绍如何基于 Qwen3.5 4B 微调一个类似 Jev 的分类模型，训练成本约 17 美元、耗时约 25 分钟。教程从 Hugging Face 的多个数据集采样 38,340 条样本，经 fetch_sources.py 和 build_all.py 归一化后，用 Together 微调服务训练，再部署到 1x_nvidia_h100_80gb_sxm 专用端点并通过 HTTP 接口调用。作者同时上线了 together/Tev1-4B-experimental，不想自行训练的用户可直接在 Together 无服务器平台使用。
#教程/实践#数据/训练#部署/工程
#产品更新#多模态#MCP/工具调用
Anthropic 发布 Opus 5.5 使用指南，说明它在 Claude 应用和 Claude Code 中的提示词写法、长任务引导和结果检查方法。指南建议一次性交代完整任务并写明完成标准，删除“think carefully”等要求思考的语句，因为 Opus 5.5 每次回复前都会自行决定思考量。长任务可在 CLAUDE.md 中规定何时停下询问、何时继续，并把任务清单写入文件以应对上下文窗口被填满后的摘要压缩。
#教程/实践#Agent#编码
SpaceXAI 在客服团队中部署 Grok Bot，在合并后工单量增长 175% 的情况下没有新增招聘，并称否则可能需要多招 200 人。Grok Bot 接入 Plain 工单系统和 Linear 问题跟踪，先以内部备注和人工审批方式验证，再逐步直接回复客户，单张工单解决成本最低可到 0.20 至 0.30 美元，而传统 AI 客服工具按每次解决收取 1 至 4 美元。它还负责实时调整队列优先级、自动判定并上报事故、每天汇总 2 万多条产品反馈，并已实现 Grok Bot 训练其他 Grok Bot。
#行业动态#Agent#部署/工程
LiveKit 官方博客对比了实时语音与视频 AI 智能体两大开源框架 LiveKit Agents 与 Pipecat，指出前者基于自家开源 WebRTC 与 SIP 服务、抽象层级更高，后者不预设传输层、需自行逐级组装 pipeline。文章还说明 TEN Framework、Dograh、Vision Agents、Vocode 的定位，并从语言支持、维护活跃度、上手速度和生产就绪度四方面给出选型建议。
#教程/实践#语音#视频
GitHub 用 GitHub Copilot app 和 Copilot CLI 把 Copilot agent runtime 从 TypeScript 完全重写为超过 80 万行生产级 Rust，代码主要由 AI 智能体编写，拆成 128 个 PR 增量合入 main，而非一次性切换。到 8 月 21 日运行时已是 100% 生产 Rust，共 832,378 行生产代码和 468,689 行 Rust 单元测试，另有 174,675 行 E2E TypeScript 测试。作者称这一原本需要整个团队一到两年的项目，主要由一名开发者用几个月完成，期间团队其余成员继续扩展运行时能力。
#行业动态#编码#Agent
Google Developers Blog 发布零信任智能体系列第二部分，在 Gemini Enterprise Agent Platform 上用 Model Armor、Semantic Governance Policies 和 Agent Anomaly Detection 三项托管运行时治理替代自建容器与正则列表。文中以同一个客服退款智能体演示三类攻击：边缘拦截提示注入、在工具调用执行前按自然语言策略拒绝数字软件许可证退款、以及通过会话遥测发现跨多轮累计套取退款的行为。配套开源仓库 zero-trust-agents-2 可本地运行，包含交互式仪表盘和 ./demo/run_part2_demo.sh 演示脚本。
#教程/实践#Agent#安全/对齐
Fireworks 对 DeepSeek-V4.1-Flash 做了完整基准测试，在 DeepSWE 上达到 GPT-6 Astra 级别的编码精度，单任务成本 0.43 美元，比 Gemini 3.8 Flash 低 5.5 倍、比 GPT-6 Astra 低 15 倍、比 Claude Opus 5 低 28 倍。该模型为 552B 参数 MoE，采用编码器-解码器分离架构，输入 8B、输出 16B 激活参数，KV Cache 相比 DeepSeek V4 仅占 1/4 HBM 和 1/8 SSD 存储，本次运行 99.6% 输入 token 命中缓存。在 HLE 上它单独运行得 34.52%，落后于 Astra 的 50.40%，但与 Astra 组成 oracle router 后达到 54.80%，高于 Astra 单独运行。
#评测/基准#编码#部署/工程
n8n 比较了确定性、动态和智能体三种流程编排模型，分别侧重可审计的固定逻辑、根据实时反馈调整，以及在确定性护栏内委派 AI 智能体处理非结构化任务。文章还梳理了编排器瓶颈、状态损坏、服务间 schema drift 和分布式故障调试等生产挑战。
#教程/实践#Agent#部署/工程
反思模式让 AI 智能体通过生成、反思和修正三个阶段检查错误并改善输出。文章比较单模型自我反思、多智能体反思和工具增强反思，并指出应设置迭代停止条件，以控制模型 token 消耗、计算成本和延迟。n8n 可通过多个 AI 智能体节点和子工作流实现生成与批评流程，并跟踪 token 消耗及成本。
#教程/实践#Agent#推理
模型上下文协议（MCP）以开放标准连接大语言模型与外部数据源和工具，让 AI 智能体可在运行时发现工具并执行多步工作流。文章解释了 MCP 客户端与服务器架构、相较传统 API 的差异，以及它如何把 MxN 点对点连接简化为 M+N 连接；ElevenLabs 产品既可作为 MCP 服务器，也可作为客户端。
#教程/实践#Agent#MCP/工具调用
Google Developers Blog 介绍 autofinetune 项目，把自主研究循环用于 LLM 后训练，基于 Tunix、Gemma 和 Cloud TPU，由 Antigravity CLI 与 Gemini Flash 3.7 编排。第一个实验中智能体在 Cloud TPU v5e-1 上对 functiongemma-270m-it 自动调整 LoRA rank/alpha、优化器和学习率等，几小时内完成 20 次实验；第二个实验基于 Tunix 官方 GRPO 示例训练 Gemma 3 1B 做数学推理，在 Cloud TPU v6e-1 上跑 40 次实验，总奖励提升约 10%。代码、示例运行和 program.md 模板已放在 autofinetune GitHub 仓库。
#教程/实践#Agent#数据/训练
MCP 让 AI 智能体在运行时发现并使用工具，API 则通过固定端点完成可预测的软件通信，两者在生产系统中通常结合使用。确定性步骤适合直接调用 API，无法预先确定调用顺序的任务可由 MCP 支持；n8n 可在同一工作流中调用 REST API、连接外部 MCP server，并将工作流暴露为 MCP 工具。
#教程/实践#Agent#MCP/工具调用
How to build great evals — Part 9 The Eval Roadmap Problem Most evals fail because teams treat them as static artifacts while their users expectations and behaviors have evolved. Your evals need a roadmap that evolves with your product and actual usage patterns. Take a financial research agent. Here is how use cases will evolve over time. Early user: Summarize this 5-page earnings report. 3 weeks later: review the last 5 earnings reports and explain their growth story. 2 months later: Here are 15 filings, earnings transcripts and research reports. Build an investment thesis. Eventually: Monitor my stock portfolio and tell send me alerts when something materially changes my thesis. Each stage requires different capabilities and hence different evals. Your evals should change with usage patterns: short-context -> long-context single-turn QA -> multi-turn passage citations -> doc and line citations Simple QA -> complex synthesis reactive chat -> proactive agent If your evals are stuck in week 1 while users are in week 3, it will show in your product and churn metrics. Here’s a practical way to build the roadmap: 1/ Map the dimensions along which usage will evolve (eg # turns, document size, tool use, autonomy, journey coverage). 2/ Prioritize the use cases and dimensions that matter most for your product. 3/ Talk to your users, mine production traces to look for shifts. 4/ Build P0 evals for the next stage of usage. 5/ Run the evals, find failure modes (remember the taxonomy from Part 3), and hill-climb (from part 6). The goal is to stay ahead of usage patterns. PM 101. Drop your questions and I will address in future posts. Share this with your teammates who think your evals are perfect.
#教程/实践#Agent#MCP/工具调用
Chips and Cheese 作者 Chester Lam 用 Geekbench 7 实测 Windows 11 的 Prism 二进制翻译，发现 x86-64 程序经翻译后执行的 aarch64 指令数约为原生两倍，各核心均出现数代性能损失。测试在 Snapdragon X2 Elite Extreme X2E-96-100 笔记本和 Azure 上的 Neoverse N1、N2 实例上进行，Snapdragon 的 E-Core 与 P-Core 即使承担翻译损失仍分别超过 Neoverse N1 和 N2。作者还查看 C:\Windows\XtaCache 中的翻译代码，指出 Prism 会做不必要的寄存器溢出，并把 256 位 AVX 运算拆成多条 128 位 NEON 指令。
#评测/基准#端侧#部署/工程