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. Eino 如何实现多智能体

1
2
3
4
5
6
7
8
9

                           ┌────────────────────────────────────────────────────────┐
                           │            Eino 多智能体协同体系 (Multi-Agent)            │
                           └──────────────────────────┬─────────────────────────────┘
                                                      │
         ┌────────────────────────────────────────────┼────────────────────────────────────────────┐
         ▼                                            ▼                                            ▼
【范式 1: Host Multi-Agent】              【范式 2: Agent as a Tool】                 【范式 3: State Graph 协同】
• 机制: 意图识别分发 + Summarizer 聚合       • 机制: 主控 Agent 将 Sub-Agent 包装为 Tool    • 机制: 强类型全局状态机 + 条件边流转
• 适用: 专家分流 (客服/风控/导购)             • 适用: 深度自主规划、跨领域能力委派              • 适用: 复杂闭环业务、自反思、Saga 事务

1.1 Host-Specialist 模式（基于 Flow 集成）

Host Multi-Agent 是 Eino 官方封装的高内聚开箱模式。
Host 负责理解用户 Query 并做意图路由，分发给一个或多个 Specialist Agent，最后由可选的 Summarizer 模块聚合成最终流式输出。

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）的。

1. 概览

一句话总结：协议从”有状态、靠长连接”变成”无状态、靠 HTTP 请求”。

2026 年 7 月 28 日，MCP 发布了算得上”有史以来最大”的一次规范修订。
同一时间，官方四套 Tier 1 SDK(TypeScript、Python、Go、C#)同步更新。

MCP SDK 月下载量已突破 4 亿（TS/Python 累计超 20 亿），部署服务器过万；
但新规范生态跟进极慢，抽样 1470+ 公开服务器中完全合规的仅 2 个，尚未出现全面切换。

2. 变更的初衷和重点

2.1 为什么改

MCP 2024 年诞生时，本质上只是为单机笔记本设计的协议：

• 一个客户端、一个服务器、一条 stdio 管道、一个与进程同生死的长连接会话（Session）。
• 对本地单机调用而言，这个设计极其精准且够用。

但当它被推向生产环境时，企业不得不为这套“本地模型”付出四笔沉重代价：

• Serverless 适配瘫痪：旧协议强依赖长连接和 Session，而 Serverless（AWS Lambda、Cloud Run、Cloudflare Workers）没有常驻进程，在物理层面就无法运行。

1. 读后感

全球化时代，你中有我，我中有你。
短时间内很难撇清关系，虽然很别扭，但是还得拉着脸合作。
新时代的竞争，和冷战差不多，甚至更严重，双方都制造假想敌，不断竞争。
提出假想敌的那些人也可能是为了让自己多争取点资源，扩大自己的一亩三分地。

1.1 金融

SWIFT 系统（环球银行金融电信协会）是全球金融机构用于安全、标准化传输支付和交易指令的主力通信网络，连接了200多个国家和地区的逾11,000家机构。它本身不持有资金或提供账户结算，而是传递促成资金流动的加密报文。
它是美元清算纽带，全球贸易超 80% 依赖美元结算。美国通过控制美元清算系统（CHIPS），对主要通过 SWIFT 传递的美元交易拥有实际上的否决权。
替代网络：为降低对西方主导系统的依赖，各国正推进如中国的人民币跨境支付系统（CIPS）或多边央行数字货币桥（mBridge）等替代和互补基础设施。

俄罗斯：俄乌战争发生后，欧美迅速把俄罗斯踢出了 SWIFT，还把存在欧洲的外汇储备给冻结了。
结果跨境贸易瘫痪、外汇收入归零、货币剧烈贬值、通道成本飙升、外资加速外逃，最后可能得回到以物易物。

林振月蛾：由于 2020 年香港某法案实行后，被美国制裁。
所有银行都不敢给他开户，包括中国的银行，因为都怕被踢出 SWIFT 系统，没法处理外汇相关业务。

1. 概要

Agent 时代，能够加速的是执行过程( 编码、调试等 )

• 说明：执行过程最多占开发活动的 50% 时间，来自 Portman 的数据

但涉及到目的、判断等核心的流程，还是需要人工介入。
由于执行过程足够快，需要人工介入的工作会越来越多，瓶颈还在人，提效会遇到天花板。
从某个角度讲，AI 加速了我们的生活，其实是变相地增加了人生的长度( 犹如开倍速看电影 )。

如果通过 Agent 进行 Coding，关键的约束：

• 从需求开始就让 Agent 了解
• 和 Agent 不断对话沟通，形成决策纪要和执行计划
• 执行计划尽量细化，每个步骤尽量有过程约束，而不是指标约束。否则容易作假
• 如果 Agent 给出的结果不好，不要直接修改代码，而是修改执行计划，说清楚来龙去脉
• 执行过程中有遇到不明确的，让 Agent 不要自己发挥，需要人工补全确认
• 如果上下文耗尽等导致效果不佳，重新开一个窗口按执行计划让 Agent 接着工作( 有状态+业务上下文 )
• Code Review 等也用新窗口拿着执行计划执行，避免不干净的上下文影响

核心就是让 Agent 有足够的上下文，有可验证的过程产出，而非简单的评估指标。

2. 精简笔记

《人月神话》是 Fred Brooks 1975 年写的一本管理书。
他管过 OS/360，那是 IBM 的大型机操作系统，1960 年代人类做过的最大一次软件工程。
项目结束他没写技术总结，写了一本关于为什么大项目总是延期、为什么加人只会加得更慢、为什么概念完整性是设计的最高目标的书。
《人月神话》写完之后成为整个软件行业的地基。
+++
Brooks 那本书的第一批读者是 1970 年代的项目经理。这本书的读者是 2026 年之后的开发者。
中间隔了半个世纪，一切都在变，唯有一件事没变：软件工程的核心是判断的组织( 把各种决策判断有机整合 )。
软件最贵的成本是维护与演进。好的组织方式，能让你在“增加新判断”或“修改旧判断”时，付出最小的边际成本。
+++
在 Agent 时代卓越的工程师，
应该投时间在判断和决定的文档上，
文档写成能被机械执行的源码级材料，
因为代码是 Agent 从文档编译的产物。