- 博客(153)
- 资源 (5)
- 收藏
- 关注
RSS订阅
原创 Codex 会话运作机制原理：一棵 Agent 树的生长与协作
是Codex 的对话 thread 对象的协调者，它负责决定“这个 thread 是复用已有运行时，还是新建一套运行时”，并在运行时创建完成后把它注册到内存中的。
2026-07-04 14:28:10
472
原创 Codex Harness 上下文工程设计原理
这是最基础但也最直观的压缩方式。核心思路是：用一段特殊的提示词让模型回顾整个对话历史，生成一份"交接摘要"，然后用这份摘要替换冗长的原始历史。如果清楚常规的压缩策略的，可以看Langchain的记忆策略。需要注意的是，摘要生成后，codex 不是简单地用摘要替换所有历史，而是执行一个精密的"筛选+拼接"算法这个算法的精髓在于从最新到最旧的贪心选择策略从最新的用户消息开始向前遍历，优先保留最新的信息在 20,000 token 的预算内，尽可能多地保留完整的用户消息。
2026-06-15 20:09:23
461
原创 Codex Skill 上下文预算控制的精妙设计（原理）
这里分析的内容对于Codex上下文管理，只是冰山一角，例如去重机制、安全阀控制都没有说到。但是也是收益匪浅。Skill 系统的核心矛盾是无限增长的能力描述 vs 稀缺的上下文窗口。Codex 的应对方式不是"超了就砍"，而是构建了一套分级的资源调度体系——预算计算定边界、目录裁剪在边 界内分配、内容截断防溢出止损。每一级都比上一级更激进，但都有明确的触发条件。按需。目录始终注入，因为模型需要知道"有什么可用"——这是基础需求，不可省略。
2026-06-14 15:32:36
597
原创 Codex Harness工程 Skills架构设计原理
在turn_run初期扫描并缓存所有可用Skill的元数据，构建目录索引始终注入模型上下文；用户触发时按需注入完整SKILL.md内容；资源文件由模型自主读取；整个过程受上下文预算控制，超预算时按层级优先级裁剪。Skill系统要解决的根本矛盾是：大模型的上下文窗口是稀缺资源，而可扩展的能力描述是无限增长的。如果没有Skill系统，扩展模型能力的方式只能是：每次对话都把所有可能的指导信息塞进去。但这在工程上不可行——128K的上下文窗口装不下几百个Skill的完整内容。
2026-06-13 20:34:52
800
原创 Codex Harness 安全沙箱机制原理
很多人第一次接触沙箱，会把它理解成“一个隔离目录”或者“一个受限容器”。这种理解不能说错，但不够本质。沙箱环境更准确的定义是：让一个执行体可以运行，但只能在被限制的能力边界内运行。这个“边界”不是抽象概念，而是具体的资源访问边界。最常见的通常有三类：文件系统边界：它能读哪些目录，能写哪些目录。网络边界：它能不能联网，能访问哪些目标地址。系统能力边界：它能不能启动子进程，能不能访问桌面、设备、注册表、系统接口。
2026-06-13 20:22:39
545
原创 Codex Harness 安全沙箱机制原理
很多人第一次接触沙箱，会把它理解成“一个隔离目录”或者“一个受限容器”。这种理解不能说错，但不够本质。沙箱环境更准确的定义是：让一个执行体可以运行，但只能在被限制的能力边界内运行。这个“边界”不是抽象概念，而是具体的资源访问边界。最常见的通常有三类：文件系统边界：它能读哪些目录，能写哪些目录。网络边界：它能不能联网，能访问哪些目标地址。系统能力边界：它能不能启动子进程，能不能访问桌面、设备、注册表、系统接口。
2026-06-11 20:42:40
898
原创 LangChain Middleware：Agent 里的 AOP 治理层
Claude Code 的 settings.json 支持 permissions.allow、permissions.ask、permissions.deny 等规则，并且规则按 deny、ask、allow 的顺序匹配，先匹配的规则生效。未来真正有价值的 Agent 架构，不会只比谁的 Prompt 写得好，也不会只比谁接了更多工具，而是比谁能把模型、工具、状态、记忆、权限、成本、安全和可观测性组织成一个可长期运行的系统。但能不能执行，不应该由模型决定，而应该由系统的权限、风控、审批和幂等机制决定。
2026-06-07 19:26:27
418
原创 AI大模型如何从“回答问题”走向“发起行动”
模型知道要调用工具还不够，它必须用应用程序能解析的格式表达出来。这就是 OpenAI、Claude、DeepSeek、Gemini 等厂商定义 tool calling 协议的原因。模型不会直接返回一句“我要查询订单”，而是返回结构化数据，例如工具名、参数、调用 ID 等。这一层的本质，是把自然语言意图转成机器可解析的结构。没有协议层，应用程序就很难稳定判断模型到底想调用哪个工具、传什么参数。
2026-06-07 13:01:17
250
原创 Harness Engineering 如何让智能体可靠落地
Harness Engineering 并不是凭空出现的，它是 Prompt Engineering 和 Context Engineering 的自然延伸。三者构成嵌套关系。大模型能力越来越强之后，很多团队会自然走过三个阶段。开发者主要关心怎么把问题问清楚，怎么让模型按照指定格式输出，怎么通过 few-shot 示例提升效果。这个阶段适合问答、总结、改写、分类、结构化抽取等相对明确的任务。Prompt 的措辞、格式、示例。
2026-06-06 18:57:37
298
原创 Agent 时代：大模型从对话走向行动
传统大模型应用开发的主要优势在于依赖 LLM 对自然语言的理解与生成能力，在给定上下文和预置流程下，能够完成问答、总结、改写、邮件润色、闲聊等相对明确的任务。从工程架构上看，它本质上更接近一种确定性流水线：开发者提前设计好 Prompt、检索、模型调用、结果解析等执行步骤，模型只负责在固定环节完成语言处理。一旦面临任务复杂度升高，涉及多步骤协同、动态决策、外部系统交互、工具调用和执行结果反馈时，传统大模型应用就容易暴露局限。因为它的执行路径通常是预先编排好的，缺少根据环境变化持续调整任务策略的能力。
2026-06-06 15:30:53
423
原创 高并发系统流量治理的底层算法
核心是“细粒度时间切片 + 滚动统计”，通过将大窗口拆分，让流量统计从“粗粒度”变为“细粒度”，实现“实时滚动、平滑统计”。其核心目标是“在简单实现的基础上，提升限流精度，解决临界区突刺问题”，兼顾落地成本和限流效果。相对于固定窗口算法，滑动窗口算法通过滑动滚动的方式，实现了任意时间范围内的请求量限制，有效削弱但无法彻底解决临界突刺问题。从原理上看，滑动窗口本质是把大时间窗口切分成更小粒度的分片窗口不断滑动统计，例如将 1 秒拆分为 10 个 100 毫秒的小窗口。
2026-06-14 17:54:45
709
原创 系统安全架构设计
Anti - DDos全称分布式拒绝攻击防护，用于防洪水、防人海攻击、流量清洗，核心防护DDos攻击、CC攻击Denial of Service（Dos攻击）→ 拒绝服务攻击 ， 本质上就是利用单台设备，疯狂轰炸你的网站 / 服务器，它不在于偷取的信息，而是在于通过网络轰炸来让你的宽带、端口、连接等资源耗尽崩溃。DDos是Dos攻击基础上的分布式攻击，即n台设备的联合轰炸。流量洪水攻击海量垃圾数据包灌进来，直接把宽带跑满。SYN 洪水只发连接请求，不完成握手，耗尽服务器连接队列。
2026-04-26 14:04:30
551
原创 VMware虚拟机网络技术
虚拟网卡是由虚拟化平台在软件层面模拟的 NIC，它在虚拟机与虚拟交换机之间承担以太网帧的收发，并通过主机内核与实际物理网卡桥接、NAT 或直通，从而让虚拟机像独立主机一样参与网络通信。因为现在虚拟机在一个独立的虚拟局域网中，所以我们需要完成虚拟NAT（类似于路由器）的配置，例如子网IP（明确网段），子网掩码（确定网络段），网关地址，因为虚拟局域网是完全独立的，因此网关完全可以与真实局域网不同。虚拟机本身作为局域网的一员，占用局域网IP资源，在IP不足的情况下则无法使用更多的虚拟机，此时引入了NAT模式。
2026-03-10 11:37:07
424
原创 企业Camunda异常处理方案
IoMapping和活动的行为处理实例都是通过AbstractBpmnParseListener抽象的解析监听器进行绑定的，因此我们可以对其相关方案进行重写/*** 重写ExclusiveGateway解析方法* 设定自定义的CustomExclusiveGatewayActivityBehavior* */@Override@Override// 复制原始 input/output= null) {
2026-03-10 10:58:37
390
原创 深入操作系统零拷贝技术
零拷贝（Zero-Copy）技术是一种优化方法，旨在减少数据传输过程中不必要的内存复制操作，可以快速高效地将数据从文件系统移动到网络接口，传统的数据传输方式通常涉及多次内存复制，这不仅消耗大量的 CPU 资源，还增加了延迟。零拷贝技术通过尽量减少或消除这些复制操作，提高了数据传输的效率。大白话说就是这是一种数据传输过程的资源优化，这里所谓的数据传输过程，更多体现在磁盘读取数据到发送过程，比如kafka从磁盘持久化读取数据发送，redis加载持久化数据，还有公司想要做的静态文件数据仓等等。
2026-03-10 10:08:09
405
原创 Camunda引擎流程推进原理
执行流可以理解为一个流程实例在运行态执行的流程，比如从A->B->C，引擎就是按照这样的流程进行任务的推进，但是需要注意的是，一个流程可能会有多个执行流，例如引擎推进到了并行网关之后，会为后续每一个分支都创建一个新的执行流（子执行流），这些执行流之间互不干扰，可以并行独立推进。P：并行网关并不是独立的线程执行，在没有异步任务的情况下，都是由主线程或根执行流线程串行执行，所谓的并行网关，指的是不同的执行流逻辑上的独立执行互不干扰。底层对于日志记录行为，采用了事件的发布订阅模式实现。
2026-03-09 18:48:39
424
原创 Innodb中CRU运作流程与持久化
例如发起select查询id=1的数据首先mysql服务server会从内存空间的缓冲池BufferPool中缓存页中查找是否存在id=1的数据，如果存在则直接返回，注意磁盘B+Tree查找过程中，通过索引查找时，实际被用到的索引页，也会放入缓冲池中。如果缓冲池中不存在缓存数据，则通过IO操作，去磁盘中读取.idb文件，将整个id=1数据所在的数据页加载到缓冲池中，成为缓存页。数据的读取可能会影响到LRU、Free链表数据，例如当数据页从磁盘中加载到缓冲池时，数据页会被指向到LRU链表的中间位置（旧子列表的
2026-03-09 17:44:33
366
原创 单机可靠性-持久化设计方案
单机持久化只是可靠性保障的基础，无法避免单点故障问题，一定要将单机可靠性转为分布式集群可靠性，通过复制模型来保障系统可靠和高可用。
2026-03-09 17:38:32
396
原创 快慢指针-Floyd判圈算法
1、1、因为快指针比慢指针速度快，所以如果链表中不存在环时，快慢指针永远不得相遇，直到Fast移动到尾部结束，时间复杂度O（n），因为Fast指针速度是Slow指针两倍，所以当Fast指针到达尾部时，Slow指针走了一般，即可求中间值。即：在第一次相遇时，PC和AC的长度是一样的，因此此时将任意节点重置到A位，并两者均以相同的速度前进，必然会在C点相遇，因此C点为入口点。假如快慢指针此时都在环内，他们相距距离为N，因为环是无效可以循环的，假设次数S指针在F指针前，即S-F=N。
2024-01-15 18:19:47
1834
1
原创 企业慢SQL案例分析
4、b表使用到了索引material_requirements_detail_k001，索引使用栏位tenantsid，eoc_company_id，eoc_site_id，Server层过滤栏位wo_no、op_no、item_no、item_feature_no、plan_date ，扫描行数2359，成本8669.88，哦豁！在索引最后加上eoc_site_id。在c表执行计划中，使用到了wo_wo_no_IDX索引，且索引栏位为wo_no ，同时存在索引过滤index_condtion。
2023-12-26 17:59:59
1140
原创 索引成本计算和优化建议
trace成本分析时可以根据索引成本结果来分析索引选择过程，但是索引成本结果并不是最终执行计划结果，最终的执行计划成本best_access_path，会基于索引成本结果进一步修正，比如每个表的大小、碎片率和使用率不同，所以最终的成本也会不同、另外还有根据当前的系统负载来调整成本。1、索引目的就是快速的定位数据，得出扫描数据，即扫描数据越少索引成本越低，效率越快。2、并不是有了索引就能使用到索引，通过SQL执行流程和成本评估，当扫描行数过大，同时需要回表时，可能最终的成本很高，这时可能会走全表扫描。
2023-12-25 19:46:17
1730
原创 深入了解SQL处理流程原理（Server层与存储引擎交互、数据管理结构）
1、ICP原理：server层在生成执行计划时，会将不能通过索引查询，但是可以利用索引结果进行过滤出的条件下推到存储引擎进行数据过滤，这样可以进一步过滤掉数据，减少后续回表的操作。简单的说，存储引擎本身是一个比较单纯的服务组件，它只负责与硬件交互，进行数据的读取和存储工作，而这一切的读写行为都是按照Server层提供执行计划来实施。2、回表原理：因为索引树中叶子节点数据不能满足需要的栏位，所以需要通过主键ID，到主键索引中查询，这是IO操作，所以要尽量的减少这样的回表操作。
2023-12-23 19:22:31
1252
原创 慢SQL减少回表手段
我们知道对于二级索引来说，索引结构中只会存储索引列信息+主键ID，如果需要额外的资讯信息，需要通过主键ID到聚簇索引结构中检索，这样的过程叫做回表，那索引覆盖的本质就是期望可以一次性通过二级索引拿到需要栏位资讯，较少回表操作。然后，存储引擎通过使用索引条目来评估推送的索引条件，并且仅当满足该条件时才从表中读取行。需要注意的是索引覆盖是为了减少回表次数，而二级索引是用于提高检索效率，需要遵循最左原则，如果在已存在的二级索引上进行索引覆盖操作，注意不要影响二级索引的正常使用，建议覆盖栏位滞后。
2023-12-12 16:41:25
1025
原创 慢SQL诊断
mysql提供了show profiles和show profile语句提供的分析信息相当的数据，但是需要注意的是在未来的mysql中会弃用当前语句功能，使用性能模式performance_schema来替换，从8.0版本文档中确实没有看到这个语句了，但是听别说依旧可以使用，这个先不管了，反正目前看来mysql5.7在23年10月还在更新维护，那就没什么好说的。mysql 默认是关闭slowlog的，不记录管理语句，也不记录不使用索引进行查找的查询，毕竟这也是一个额外的损耗。具体的使用可以根据需要来定。
2023-12-05 16:58:01
1681
1
原创 Innodb-ruby深入探索Innodb存储结构
这也正对了前面说到的最左原则特性。之前理论知识也说过了，目录页会记录最小索引列编号，来作为目录检索，比如查询34000，那就是在33819~34232区间，指向page 6 号数据页里面，这个时候就会去6号page页检索。这里可以看到在查看了page为3（PRIMARY索引的root页）的页信息后，一共出来95个page信息，对应了上述表述的95个leaf page，同时默认按照主键ID从小到大排序。可以看出来在二级索引的leaf节点中，是没有完整的数据信息的，处理索引列数据，还存储了主键id信息。
2023-12-02 15:56:51
1547
原创 记一篇Centos7安装innodb_ruby
yum安装ruby默认的会安装ruby2.0.0版本，但是在安装innodb_ruby时，会报错，提示至少需要2.4版本以上才能安装。安装innodb_ruby过程非常坎坷，这里记录下安装过程，有些坑当时没有记录下来，主要把完成安装过程就记录下来。这个就比较方面了，直接进入到ruby2.5.0 目录执行卸载程序， make uninstall即可。下了很久很久，后面找了国内镜像地址下载了.....反正哒哒哒一顿安装，结果在下载时候完全卡死。于是赶紧利索的将yum安装的ruby版本卸载了。
2023-11-29 18:22:37
1073
原创 Linux安装MySQL 5.7
看到一篇安装Mysql5.7的帖子，比较详细，亲测验证过，这里做个记录转发：Linux安装MySQL 5.7_linux 安装mysql5.7-优快云博客
2023-11-29 10:50:38
469
原创 大数据量条件SQL查询内存处理方案以及数据过滤算法优化
在索引分析时，需要注意的是，并不是SQL有使用到索引就排除索引问题，执行计划索引分析时，需要关注type栏位，判断出当前是否使用到索引，以及索引使用类型，range、index、all都是需要被重点关注的。评估使用索引栏位查询后的数据量，比如以上案例tenatsid为wo_detail索引栏位，则查看该租户下数据量，如果数据量为2w以内（这里为初略标准，具体可以根据需要输出的栏位以及数据量做内存评估），思想是，在一定数据量前提下，利用索引快速查询冗余数据，同时结合内存快速过滤需要的数据。
2023-11-23 17:39:09
1003
原创 实战JVM高CPU、内存问题分析定位
所以程序执行过程中可能产生了大数据量，导致了大对象的诞生，根据Jvm内存分配原理，大对象会直接放入到Old区，并发场景下Old区很快就会被大对象吃满，从而引发FGC。结合当前程序分析后发现，当前API虽然支持分页查询，但是在获取total时，使用原SQL查询所有数据，然后获取size，导致了获取到了7w多笔数据，导致了效能问题。这里可以看到执行了一次API后，Old区上升了约350m，正如上面我们推测的，当前API产生了大对象，直接放入到Old区，并发后导致内存吃满。再PR程序调整后，验证结果。
2023-11-23 17:31:34
782
原创 Kakfa - Producer机制原理与调优
在早期版本的时候元数据是存储在zookeeper中的， 元数据指的是集群中分区信息、节点信息、以及节点、主题、分区的映射关系等。在生产者启动的时候没有元数据的支撑，是无法进行数据的发送的，等于瞎子。metadataUpdater.maybeUpdate方法在第一次被执行时，因为没有元数据节点信息，会执行this.maybeUpdate(now, node)方法，方法内部实现了initiateConnect方法用于客户端建立连接，其底层就是使用的Java Nio的Selector多路复用器。
2023-09-17 16:21:31
669
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人