这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
《互联网产品的 AI 架构·平台化与治理》1.2 治理的四个对象：能力、调用方、租户、版本
治理不是给网关再加一层看板，而是先回答「治什么」。本节把能力、调用方、租户、版本四个对象各自的字段、关系与校验规则写清楚，用一段确定性代码检查对象存在性、引用一致性与语义合法性，并说明为什么只有网关加预算时，重复建设、版本漂移与责任不清仍然无法被发现。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
《互联网产品的 AI 架构·平台化与治理》1.1 从一条链路到很多条链路：回声的规模化现场
回声从三条链路扩到多团队、多租户后，治理问题不再是单条链路的重试与预算。本节把能力重复、版本漂移、配额争抢、责任不清四类冲突写成可判定的检测条件，用示例样本跑出 4 条冲突记录，并说明为什么仅有网关加预算，无法回答所有权、版本与退役计划的问题。
《互联网产品的 AI 架构·平台化与治理》目录与学习路径
《互联网产品的 AI 架构·平台化与治理》的完整目录与学习路径：13 章 39 节从治理对象与职责边界、能力目录与所有权、版本兼容，讲到多租户配额、评测平台、质量/成本/合规/安全治理、平台工程、组织流程与长期演进；附四卷回顾、三条阅读路径、实验工程与十五个治理问题。
《互联网产品的 AI 架构·平台化与治理》前言
前言交代卷四的结构与用法：13 章如何从治理对象、目录版本、配额评测走到平台化收口，src/gov 的模块地图，L1/L2 两级可运行性，代码块三行头约定，回声三条链路与共享数字口径，八周阅读节奏，代码验证方法，以及本卷明确不做的三件事与团队自检清单。
《互联网产品的 AI 架构·平台化与治理》序
卷三把一条链路跑通之后，卷四要回答很多条链路、很多团队、很多租户如何共存。这篇序从回声的三个冲突讲起：同一能力被三个团队以不同档位调用、一个租户的配额打满另一个租户的峰值、一次模型换代让三份能力版本悄悄分叉，由此说明治理不是流程堆叠，而是把四类对象写进契约。
《互联网产品的 AI 架构·多能力编排与任务闭环》附录 C 编排评审清单
把卷三的判断压缩成一份可打印的编排评审清单：结构、契约、执行图、上下文、失败、人工与异步、评测、成本、权限、运维、平台化、演进与收口共十三组六十五问，每组附通过判据与常见驳回理由，末页给出四十五分钟评审流程、结论模板、上线后复盘表与三个常见误区。
《互联网产品的 AI 架构·多能力编排与任务闭环》附录 B 交接成本与失败传播公式速查
把卷三的交接与失败账目压成可直接代入的公式：交接 token 成本、复用回本线、整链成功率、单步失败预算、重试放大、并行分支期望延迟、节点预算分配与裁剪顺序、每次成功交付成本；每个公式给出变量、代入示例、适用边界与对应章节，并给出一张联用顺序表。
《互联网产品的 AI 架构·多能力编排与任务闭环》附录 A 编排模式与判据速查
把卷三用到的五种编排模式压缩成一页可查的判据表：串行、并行（all/any/quorum）、条件分支、人机混合与异步交付，每种给出结构图、适用判据、成本与延迟特征、典型失效方式及对应章节，并附模式选择表与四个提问，帮助在方案评审时快速排除不成立的编排结构。
《互联网产品的 AI 架构·多能力编排与任务闭环》13.3 进入卷四：平台化与治理
卷三用三条链路、五个门禁与一次评审回答了多能力怎么协同。本节把结论压缩成五条交接输入，并把卷四要处理的多团队共享、多租户配额、评测平台、合规与长期运营四个问题逐条展开，说明哪些问题在单团队编排里已经解决、哪些必须换一层架构，并给出能力目录与配额的衔接方式。
《互联网产品的 AI 架构·多能力编排与任务闭环》13.2 一次编排方案评审
C 链路 95.00% 的成功率没到 97% 目标，团队提出给下单动作补幂等键与一次补偿重试。本节给出一份可归档的方案评审记录：方案、基线、改动、预期、条件、负责人、复查日期，逐项列出通过项与四条驳回项，并附可复用的记录模板与灰度条件说明。
《互联网产品的 AI 架构·多能力编排与任务闭环》13.1 回声的编排基线
三条业务链路各跑 240 条确定性样本：A 内容审核 96.25% 通过，B 会话回复 239/240，C 检索下单 95.00% 未达 97% 目标。本节给出节点、交接、预算、失败策略与观测字段的完整基线表，并说明每次成功交付成本、P95 与交接占比如何判定 pass/conditional/fail。
《互联网产品的 AI 架构·多能力编排与任务闭环》12.3 从固定编排到自主 Agent
固定编排与自主 Agent 的差别不是智能程度，而是路径能否枚举、步骤是否有上限、失败代价是否可承受、审计是否可复现。本节给出四项硬判据、加权评分、硬否决与一组运行护栏，并用示例样本跑出六类任务的建议，说明为什么大多数产品请求应保持固定编排。
《互联网产品的 AI 架构·多能力编排与任务闭环》12.2 编排版本与灰度
编排版本一换，受影响的不只是新请求，还有在途任务、共享状态与语义缓存。本节把灰度拆成租户、流量、任务类型三个维度，给出新旧版本并行的状态双向兼容检查与缓存隔离规则，并用示例样本跑出分流结果、四类兼容问题，以及可实际执行的回退顺序与放量门禁。
《互联网产品的 AI 架构·多能力编排与任务闭环》12.1 从单能力到编排的重构
「回声」把三个能力从业务代码直连改成编排，经历了三步：先抽节点契约，再抽执行器，最后拆链路。每一步都有验收门槛与回退动作，任何一步证据不足都不能继续，以及旧路径的移除策略。本节给出可运行的验收判定、阻断顺序与回退经济学，并用示例样本跑出三步的通过结果。
《互联网产品的 AI 架构·多能力编排与任务闭环》11.3 多团队共享能力目录
能力目录不是一张 README 表，而是多团队复用的版本契约。本节定义能力名、版本、契约、SLO、成本、所有者与变更流程七个字段，用可运行代码解决版本解析、所有者校验与升级审批，并回答「谁负责升级」，给出三档变更流程、审批规则与灰度验收步骤。
《互联网产品的 AI 架构·多能力编排与任务闭环》11.2 引擎扩展点与插件边界
引擎扩展点不是把内部函数暴露出去，而是用四类稳定接口换取可治理的多样性。本节定义节点类型、策略、存储、观测四类扩展点与插件不能触碰的六条负边界，给出基于引擎 API 版本与 engineRange 的兼容判定、可运行注册表，并说明主次版本升级与扩展点弃用的处理顺序。
《互联网产品的 AI 架构·推理性能与成本工程》13.3 进入卷三
单能力优化收口之后，三个能力串成一条工作流会带来四类新成本：跨能力调用、上下文复用、结果传递与失败传播。本节用可复算的三能力场景跑出交接税、成功概率与回本复用率，并给卷三留下三个必须回答的编排问题，并附上可运行的 TypeScript 模块。
《互联网产品的 AI 架构·多能力编排与任务闭环》11.1 声明式编排与代码编排
声明式与代码编排的分界不在语言，而在谁维护、怎么测试、怎么灰度、能力上限在哪。本节用「回声」链路 A 的四节点定义给出四条判据与混合方案：结构声明化、节点代码化、边界固定化，说明如何同时保留可治理性、表达力与秒级回滚能力，以及哪些需求必须交回代码。
《互联网产品的 AI 架构·多能力编排与任务闭环》10.3 编排事故的止血与复盘
摘要节点的单步失败率升到 12%，整条链路成功率掉到 98.12%，错误预算已经烧掉 1.88 倍。本节给出编排事故的止血顺序：停新任务、降级节点、回滚版本、保数据，再验证恢复；把顺序写成带证据门槛的状态机，并给出一张缺项就不能结案的复盘表。附可运行的 TypeScript 模块与 21 项测试。
《互联网产品的 AI 架构·多能力编排与任务闭环》10.2 节点级 SLO 与整体 SLO
整体 SLO 达标，节点 SLO 却可能已经红了。本节把三能力链路拆成串行、并行与人工节点，给出可用率相乘、延迟相加、并行取弱、人工单列的合成规则，并用示例样本跑出 99.0023% 的整体可用率如何掩盖 99.3% 的摘要节点，附可运行的 TypeScript 合成器与 21 项测试。