目录 上篇：Harness — Agent 运行时引擎 Harness 全景 两种运行模式 Agent 工厂链 中间件链 Runtime 子系统 Checkpointer 检查点系统 Store 持久化系统 Stream Bridge 事件流 模型工厂 内存 / 记忆系统 Sandbox 沙箱系统 Subagent 子智能体 Tool 系统 Skills 技能系统 Config 配置系统 中篇：身份 / 多租户 / 审计 ...
背景 在 AI 越来越发达的今天，我们传统业务开发不得不面临的一个问题是：面对越来越膨胀的 AI 写的代码，我们该如何 Review？ 不同的业务场景 AI 能够介入的效果不同。有些业务 AI 能够轻松介入，比如智慧客服、智能 OA 等等。但在 C 端支付结算领域，从来没有说过有"智能支付"、“智能交易”、“智能结算”。 ...
Harness 设计：不是外壳，而是 Agent 系统的控制结构 1. 为什么要重新理解 Harness 很多人第一次接触 harness，会把它理解成： 一个运行时外壳 一个更大的 prompt 一个会话续接层 一个帮 Agent 跑起来的脚手架 这些理解不是完全错，但都偏窄。如果只这样理解，你会看不见 harness 真正关键的部分：谁控制系统、任务一轮轮怎么推进、哪些动作被允许、出错后如何恢复、上下文预算如何治理。 ...
🏭🔧三、 抽象工厂（Abstract Factory）——“成套生娃”一条龙(抽象工厂模式) 一句话： 不再只 new 一个披萨，而是一次性 new 整套原料家族（面团+酱料+芝士）， ...
用数学思考，用代码实现：程序员真正的思考方式 很多程序员习惯“边写边想”，结果写出来的代码混乱、低效，甚至解决了错误的问题。 真正高效的做法是：先用数学把问题想清楚，再用代码精准实现。 ...
《凤凰架构》深度学习笔记 作者: 周志明 文档定位: 构建可靠的大型分布式系统的技能地图 📋 一、核心主题与结构框架 (SCQA分析) Situation (情境) 软件系统规模日益增大，复杂度持续攀升 传统单体架构难以应对大规模分布式场景 架构演进历程:大型机→原始分布式→单体→SOA→微服务→服务网格→无服务 业界缺乏系统性的架构知识地图 Complication (冲突) 墨菲定律困境: “事情可能出错就总会出错” 人员、代码、硬件、网络都存在不可靠因素 规模越大,系统整体可靠性反而越难保证 如何用不可靠的部件构造可靠的系统? Question (问题) 如何构建一套真正可靠的大型分布式系统? 不同架构风格的本质差异和适用场景是什么? 架构师在设计时应该思考哪些核心问题? Answer (答案) 核心理念: “Phoenix”(凤凰)——服务能够"涅槃重生" ...
《数据密集型应用系统设计》(DDIA) 深度学习笔记 作者: Martin Kleppmann 学习目标: 系统掌握数据密集型应用设计原理 📋 一、SCQA框架分析 S (Situation - 情境) 现状描述: 当今互联网时代,大多数应用都是数据密集型而非计算密集型 数据的主要挑战在于:数据量、数据复杂度、数据变化速度 技术生态百花齐放: NoSQL、大数据、Web-Scale、分片、最终一致性、ACID、CAP定理、云服务、MapReduce等 核心定位: ...
工厂方法模式(Factory Method Pattern) 1. 模式动机 现在对该系统进行修改，不再设计一个按钮工厂类来统一负责所有产品的创建，而是将具体按钮的创建过程交给专门的工厂子类去完成，我们先定义一个抽象的按钮工厂类，再定义具体的工厂类来生成圆形按钮、矩形按钮、菱形按钮等，它们实现在抽象按钮工厂类中定义的方法。这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新的产品，如果出现新的按钮类型，只需要为这种新类型的按钮创建一个具体的工厂类就可以获得该新按钮的实例，这一特点无疑使得工厂方法模式具有超越简单工厂模式的优越性，更加符合“开闭原则”。 ...
简单工厂模式( Simple Factory Pattern ) 1.1 模式动机 考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等）， 这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，此时，就可以使用简单工厂模式。 ...
限流简介 每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，所以就有了降级和限流。限流其实就是：当高并发或者瞬时高并发时，为了保证 ...