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 设计：让稳定性融入设计

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

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

1. 全文概览

FDE(Forward Deployed Engineer)：前置部署工程师

• 跨界翻译官：兼具技术与业务的人才，既能写代码、做系统集成，又能听懂非技术高管的商业需求。
• 驻场交付者：FDE 通常会直接“空降”或长期驻扎在客户（如律所、医院、工厂、政府部门）的业务现场。
• 破局关键人：将通用的 LLM or 软件系统 嵌入到企业真实生产环境中，解决落地难的问题。

FDE 不是一个新词，20 多年前就有，而且现在人家利润率不低。
本质上就是为效果付费，解决企业实际的问题。
由上到下进行推动，全面配合。

• 深入工作现场，了解一线员工痛点在哪，而不是等着收集需求，因为需求传递过程中会失真；
• 不做花里胡哨的功能，只为效果收费，为解决问题收费；
• 积极主动解决问题，不用等着客户催；
• 深度集成到客户现有的系统，打通数据等通路；
• 系统做好了没人用？上手难度大吗？尽量嵌入现有流程，降低使用门槛；
• 一线员工对新系统不信任？定位他们一般找谁解决问题，咨询问题，要数据等等，先搞定 KOL；

本质上来讲，这些都是软件工程里面老生常谈的问题，只是这两年 AI 能力强了之后，能解决一些脏活累活。

1. 为什么要用多智能体

多智能体不是把单个 Agent 做得更好，是用 token 换容量。

Anthropic 自建研究 Agent 时做过一组对比：以 Claude Opus 4 为主 Agent、Claude Sonnet 4 为子 Agent 的多 Agent 系统，在内部 research eval 上比单 Agent 的 Opus 4 高 90.2%。他们给的归因不是「多个 Agent 更聪明」。在 BrowseComp 评测上，token 用量单独解释了 80% 的性能方差，加上工具调用次数和模型选择，三个因素合计解释 95%。多 Agent 架构的作用在于把 token 用量扩展到单个 Agent 够不到的规模。

代价写在同一篇里：Agent 比普通对话多用约 4 倍 token，多 Agent 系统约 15 倍。原文的措辞是，多 Agent 只适用于任务本身价值足够高、付得起这个溢价的场景。

1. 系统概览

OpenViking 是一个开源的、专为 AI Agent 设计的上下文数据库。
OpenViking 通过文件系统范式统一管理 Agent 所需要的上下文（记忆、资源和技能），
并实现上下文的分层供给与自我迭代，最终目标是降低 Agent 开发门槛，
让开发者更专注于业务创新而非底层上下文管理。
与其它记忆不同的是，他既有最开始的原文，也有高层级的语义理解。
数据召回的时候，数量以及准确性，都会有较大的效果和性能提升。

说明：

• 本地安装的时候，全部可以用类似 Sqlite 的方案，依赖三方包即可；
• 数据写入后，L1、L0 阶段需要 LLM 参与生成摘要、做语义理解；
• L2 如果原文超长，可以做逻辑语义拆分，符号提取 / 虚拟子目录 / 偏移分页；

1.1 系统架构

吴恩达团队通过分析超过 10,000 个招聘信息；
对人工智能专家、招聘经理和招聘人员进行数十次结构化访谈；
通过调查收集数据；以及综合其他在线数据，总结出以下四项最重要的 AI 工程技能：

• 构建和部署人工智能应用程序( Building and deploying AI applications )
• 软件工程基础知识( Software engineering fundamentals )
• 使用编程代理( Using coding agents )
• 塑造结构( Shaping the build)

1. 构建和部署

人工智能应用与非人工智能应用的主要区别在于前者具有不可预测的输出。

去年升级了博客：Hexo 升级 & 优化，近期才发现有些 Tag 404。
但是 hexo s 本地运行的正常打开的，我看了下 Cloudflare pages 的发布日志。
判断应该是平台机制问题，生成的文件都是 java 而非预期的 Java。

于是问了下模型：

• 问题：这是 Cloudflare Pages 的一个已知机制/行为。
• 解决：通过 hexo 的配置，把 URL 都调整为小写( 可能会影响 SEO )

原因解析
Cloudflare Pages 在部署静态资源时，其底层路由系统（以及预設的 Assets 引擎）在处理 URL 和文件路径时，默认是不区分大小写（Case-Insensitive）或者会执行规范化（Normalization）的。