这篇展开上下文与成本。整体分层见《Agent 架构的 7 层模型》。

1. 缘起

9 月 23 日，Cursor 的 Eric Zakariasson 在 X 上发了一份 prompt。
内容是优化 Agent Harness 的 token 效率。
帖子说，某团队一轮改动后整体 token 成本降了约 7%，质量没有下降。
改动包括提示词精简、工具卸载、缓存布局、稀疏行号、子 Agent 调优。这是团队自述数据，用来判断量级。

它最值得抄的是方法：不看单次请求省了多少，改看完成一个任务花了多少。
李博杰的开源书《深入理解 AI Agent：设计原理与工程实践》补上了另一半，这些动作为什么有效。我写过读后感。

2026 年 8 月 4 日，硅谷101 播了一期对谈，嘉宾是盛颖。节目页给的头衔有三个：开源推理引擎 SGLang 的发起人、xAI 前推理团队负责人、RadixArk 联合创始人兼 CEO。这期还有一份近四万字的文字稿，发在硅谷101 的头条号上，本文引用的原话都出自那里。

她现在的公司拿了 1 亿美元种子轮，估值 4 亿美元。访谈里更耐看的是另外一部分：她怎么从九江走到斯坦福，为什么愿意把代码放出去，以及她怎么讲那些平时没人摆到台面上说的事。这几段放在一起，背后有一条共同的判据，她要把「对不对」从感觉变成可验证的东西：数学用证明，系统用指标，组织用规则。

落到产品上，SGLang 回答的是一个很实际的问题：同一批卡，做同一件事，凭什么有的团队能多跑出几倍的量。

1. laya 是什么

laya 是一个跑在自己机器上的判断模型：给它一段材料（工单、邮件、命令、JSON）和几个预设问题，它返回选项和概率，不生成任何文字。

它是照着 Jev 的接口做的开源替代：比 Jev 快得多、免费、能自己部署，但开箱能力弱一档，选项一多就崩，要用得先拿自己的数据微调。下面说的快和弱，参照物都是 Jev。

1.1 和 Jev 的关系

2026 年 9 月 15 日 TypeSafe AI 发布 Jev，闭源托管、邀请制。三天后 laya 出现在 GitHub 上，由 Convai Innovations 开发。

laya 复现的是 Jev 的接口和那套概念，模型本身是另一套。它是三个 encoder 加一个决策头，英文基于 ModernBERT-large 421M 参数，多语言基于 mmBERT-base 322M，权重都是自己训练的。Jev 只提供托管 API，laya 的基准测试里也从没调用过 TypeSafe 的接口，取的都是官方公布的数字。

这篇是落地案例。整体分层见《Agent 架构的 7 层模型》。

1. 概览

一个 Chatbot 要上线，关键不在模型多强，在模型外面套一圈确定性的关卡。

• 违规请求在进模型之前就被拦掉，省 token 也省风险。
• 召回来的知识先过重排再喂给模型，低分的直接砍掉。
• 工具调用套上中间件，限流、清洗、重试都在这一层做，下游不会被模型不可靠的参数打崩，出错能自愈。
• 输出过审才出去、过审才写回记忆，某一轮的错结论不会污染之后每一轮。
• 全程挂 Callback，出问题能定位到是哪个环节慢、哪个环节多花了 token。

思路是：模型能出错的每一处，都放一道确定性的关卡接着，模型只管认知，工程交给外面的关卡。

1. 缘起

2026 年 9 月 15 日，TypeSafe AI 发布模型 Jev。它不生成文字，给定一段材料与若干预设问题，直接返回选项和概率。创始人 Diogo Almeida 为 InstructGPT 论文作者之一。发布三天内，GitHub 上出现十余个围绕它的项目。

它要解决的问题：Agent 跑一次任务，中间要做几十上百次小判断，比如下一步点哪个按钮、这封邮件归哪个队列、这条命令危不危险。这些判断的答案通常只是一个选项或一个数，但交给大模型做，模型得先把答案写成一句话，程序再解析回来。成本花在两处用不上的地方：把答案写成文字，以及每问一个问题都把同一份材料重读一遍。

1. 缘起

上一篇《Agent Orchestration - 智能体编排》写的是 Eino 怎么实现多智能体，讲的是用法。

Eino 是 CloudWeGo 出的 Go 语言 LLM 应用编排框架。
它把 ChatModel、Tool、Retriever 这些组件连成图，编译成一个 Runnable 来跑。
README 里写明参考了 LangChain 和 Google ADK，所以熟悉那两个框架的人会觉得眼熟。

通过分析运行时，来了解 Eino 内部调度、状态管理、中间件、可观测等方面。

一篇关于 AI API 中转站的调研，约 1.2 万字。
从一条 6TB 数据泄露的推文说起，往下分三块：

• 这门生意怎么赚钱（第 2 节）
• 系统怎么运转（第 3 节）
• 要做成一个安全可靠的版本还缺什么（第 4、5 节）。

只想看结论，跳到 5.7 的架构图。
整篇下来最难的不是转发，是计费：上游余额根本查不准，只能估算加对账。

1. 起因

2026 年 9 月，安全研究员寿超璠在 X 上发了条推文。他花五位数美元，从国内一家头部大模型中转站买到了一批约 6TB 的调用数据。

数据没脱敏。里面有 SSH 密钥、VPN 配置、阿里云密钥、GitLab token。按他本人的说法，仅凭这批凭证就能接管 19 家中国企业（含小米、华为、蔚来）和 7 个中国及独联体政府机构。这家平台不只囤日志，还把它当微调语料在黑灰市场出售。

1. TT 开放平台都有哪些形态

「TikTok 开放平台」在日常语境里被混着用，实际至少是五套平行体系，面向完全不同的人。

这五套的开放程度是反着来的：

1. 缘起

博客攒了 300+ 篇，标签一直没管过。
前几天想找「我写过哪些关于稳定性的东西」，在标签页翻了半天没找着，才下决心重做。

原来的样子不好看。

• 124 个标签，其中 82 个只用过一次，占三分之二；
• Java 一个标签挂了 105 篇，占全站三分之一；
• 另一头是「穿布鞋的马云」「StringBuffer的区别」这种，一辈子只用一次。

标签列表点进去一半是单篇，这就不叫导航了。

1. 缘起

在大模型时代，模型响应时间以及响应内容确定性未知的情况下，怎么做好稳定性？
过去做过的经验能不能复用呢？比如高并发系统(TPS 25w、QPS 100w、TP999 < 80ms)。
我理解是可以复用的，因为本质上都是软件工程的问题，但有几处会变，放在第 3 节展开。
把事前、事中、事后这几步给做好，做扎实，怀着敬畏之心，肯定是 OK 的。

2. 全链路稳定性

全链路走六段：设计阶段留预案，开发阶段立规则，发布阶段卡流程，运行阶段看得见、扛得住，故障时先恢复再定位，复盘时把错误变成资产。
这些流程不是凭空定的，都是血泪教训总结出来的——不要因为省事而越过流程。

2.1 设计：让稳定性融入设计

把背景、约束理清楚。遇到高速增长的系统，我们要先考虑优化系统，再考虑增加硬件资源。平衡成本与收益。

• 依赖分级：把系统的强弱依赖搞清楚，强依赖尽量保证能降级；
• 失败处理：超时、重试、熔断、降级；写操作需要幂等( 网络默认是不可靠的 )；