- 博客(331)
- 收藏
- 关注
RSS订阅原创 第二篇：《KRaft 架构深度解析：Controller Quorum、Raft 共识与元数据日志》
实际上，combined 模式下 Controller 的 Raft 日志写入和 Broker 的消息写入会争用同一份磁盘 I/O 和网络资源，元数据变更的延迟会直接影响业务消息的稳定性。当 Active Controller 故障时，Raft 选举产生新的 Leader，新 Leader 本地已经有了完整的元数据，不需要从任何外部系统拉取——这就是上一篇中“毫秒级故障恢复”的架构基础。Confluent 的文档对此的描述是：快照“从内存中读取状态，而不是重新读取磁盘上的日志”，概念上类似于日志压缩。
2026-11-03 09:20:09
237
原创 第一篇：《Kafka 4.x 与 KRaft 革命：为什么 ZooKeeper 的时代结束了？》
Confluent 的实验室数据显示，在 200 万分区的集群上，KRaft 的 controller 故障恢复时间比 ZooKeeper 模式大幅缩短，官方将其描述为“接近瞬时”的故障转移。更准确的表述是：KRaft 在架构上被设计为可以处理数百万个分区，实际的可扩展性仍然取决于集群的节点数量和硬件容量——KRaft 移除了 ZooKeeper 带来的那个“硬天花板”，让规模重新回到“加机器就能扩”的轨道上。仍在 ZooKeeper 模式上的集群，必须先迁移到 KRaft，才能升级到 4.x。
2026-11-03 09:18:09
263
原创 第十五篇：《监控诊断与综合实战：从零设计一个高并发订单系统》
十五篇文章走完，你会发现 PostgreSQL 的性能、安全和可靠性，很少来自某一个“银弹参数”，而来自一组经过取舍的组合决策：索引和写入的取舍、同步复制和写入延迟的取舍、RLS 隔离和查询性能的取舍、分区粒度和运维成本的取舍。一个优秀的 PostgreSQL 工程师，不是记住最多参数的人，而是能在具体约束下做出正确取舍的人。
2026-11-02 09:17:41
304
原创 第十四篇：《安全加固：认证、授权、行级安全策略》
在上一篇文章中，我们通过内存调优和连接池让数据库“跑得稳”。但一个跑得稳的数据库如果谁都能连、什么都能看、改了没记录，它就是一个稳定运行的“数据泄露源”。默认安装的 PostgreSQL 是不设防的：本地连接默认用 trust（无需密码），远程密码用 md5（可被离线爆破），没有审计日志，每个用户对 public schema 有完整权限。安全加固要做的，是系统性地消除这些默认的“方便”，代之以最小权限、可追溯、可验证的访问控制。
2026-11-02 09:12:31
381
原创 第十三篇：《性能调优：shared_buffers、work_mem、连接池》
在上一篇文章中，我们通过 PITR 建立了“数据丢了能恢复”的兜底能力。但恢复再快，也不如系统根本不坏、查询始终流畅。性能调优要解决的是“资源怎么分配才不浪费、不打架”的问题，而 PostgreSQL 的性能调优有一个非常独特的约束：每个连接是一个独立进程。这意味着连接数不是免费的——200 个直接连接意味着 200 个进程、200 份私有内存、以及上下文切换的开销。
2026-10-30 09:56:35
167
原创 第十二篇：《备份与恢复：pg_dump、pg_basebackup、PITR》
在上一篇文章中，我们通过流复制和 Patroni 构建了高可用架构——主库故障时，备库能在数十秒内接管。但高可用解决的是“节点挂了怎么办”，备份解决的是“数据没了怎么办”。这是两个完全不同的问题：一个 DROP TABLE 或 DELETE 误操作，会同步复制到所有备库，高可用架构不仅不能保护你，反而会帮你把错误“高可用”地执行到每一个副本上。
2026-10-30 09:53:00
12
原创 第十一篇：《逻辑复制与流复制：高可用架构设计》
在上一篇文章中，我们通过全文检索让单库的搜索能力从“全表扫描”升级为“索引匹配”。但单库再强，也扛不住节点故障——主库宕机、网络分区、磁盘损坏，任何一个环节出问题，业务都会中断。复制是可用性的基础，而高可用是在复制之上的自动化。PostgreSQL 提供两种复制模式：物理流复制（字节级，整集群一致）和逻辑复制（SQL 级，按表选择性复制）。前者是高可用的基石，后者是数据分发和跨版本迁移的工具。
2026-10-29 09:08:08
257
原创 第十篇：《全文检索：tsvector、tsquery 与中文分词》
PostgreSQL 的原生全文检索正是为解决这个问题而设计的——它把自然语言文本转化为可索引的 tsvector，把查询转化为 tsquery，通过 @@ 操作符判断匹配，由 GIN 索引加速候选集合，最终用 ts_rank 给出相关性排序。查询时必须匹配索引的表达式。WHERE to_tsvector(‘english’, body) @@ ‘a & b’ 可以走索引，但 WHERE to_tsvector(body) @@ ‘a & b’ 不能——因为后者使用的是默认配置，可能和索引的配置不一致。
2026-10-29 09:07:34
593
原创 第九篇：《分区表实战：范围分区、列表分区、哈希分区》
本文从三种分区策略的选型讲起，深入拆解分区裁剪的生效条件、ATTACH 与 DETACH 的锁行为差异（这是运维中最容易踩坑的地方），以及 PostgreSQL 19 的 MERGE PARTITIONS / SPLIT PARTITION 如何让分区策略“可演进”。另一个常见的裁剪失效场景：对分区键使用函数或表达式，例如 WHERE DATE(created_at) = ‘2026-10-01’——这与 B-tree 索引失效的原理相同，分区裁剪也无法识别“函数结果”与“分区边界”之间的关系。
2026-10-28 09:04:34
643
原创 第八篇：《VACUUM、自动清理与膨胀治理》
当插入行数超过 autovacuum_vacuum_insert_threshold（默认 1000）+ autovacuum_vacuum_insert_scale_factor（默认 0.2）× 行数时，autovacuum 会运行以冻结元组和更新 visibility map，而不是等待死元组积累。GitLab 的实践：极狐 GitLab 将 autovacuum_vacuum_scale_factor 从默认的 0.2 降低到 0.02（2%） ，并对大型、频繁更新的表进一步降低。
2026-10-28 09:04:04
476
原创 第七篇：《事务与并发：MVCC、隔离级别与锁机制》
但 SQL 优化解决的是“单个查询跑得快不快”的问题，而事务与并发解决的是“多个事务同时跑时，数据还对不对、系统会不会卡死”的问题。VACUUM 的冻结（freeze）机制是唯一的防线：VACUUM 将足够旧的元组 xmin 标记为特殊的 FrozenTransactionId，表示“比所有正常 XID 都老，永远可见”。一个关键认知：在 PostgreSQL 中，UPDATE 在物理上不是原地修改——它逻辑上等价于“将旧元组的 xmax 标记为当前事务，然后插入一个 xmin 为当前事务的新元组”。
2026-10-27 09:13:29
515
原创 第六篇：《SQL 优化的艺术：从慢查询到毫秒级响应》
本文将系统讲解索引失效的典型场景、深度分页的正确解法、子查询与 JOIN 的取舍、以及窗口函数的性能边界，最后通过一个“5 秒到 50 毫秒”的完整优化实战，帮你建立从“能跑”到“跑得快”的工程能力。对于 ROW_NUMBER() 配合 ORDER BY 和 LIMIT 的场景，如果窗口函数是单调的，PostgreSQL 19 支持run conditions，允许在满足条件后提前终止分区的处理，而不是计算完整分区再过滤。游标分页天然稳定，因为它的锚点是“上一页的最后一行”，而不是“跳过的行数”。
2026-10-27 09:10:30
431
原创 第五篇：《查询优化：EXPLAIN ANALYZE 深度解读》
本文从 EXPLAIN 与 EXPLAIN ANALYZE 的区别讲起，逐一拆解计划节点的含义、关键指标（成本、行数、BUFFERS）的解读方法、四种“坏计划”模式，以及统计信息如何修复估算偏差，帮你建立从“看计划”到“诊断计划”的完整能力。四种扫描节点：Seq Scan（全表）、Index Scan（索引+回表）、Index Only Scan（仅索引，依赖 visibility map）、Bitmap Heap Scan（位图+批量回表，避免随机 I/O）。成本估算的单位是“任意单位”，不是毫秒；
2026-10-26 09:26:07
405
原创 第四篇：《索引原理与实战：B-tree、Hash、GIN、GiST、BRIN》
本文将逐一拆解 PostgreSQL 六种索引类型的工作原理、支持的操作符和适用场景，深入讲解复合索引的列顺序原则、部分索引与表达式索引的实用技巧，最后通过一个“慢查询索引设计”的实战，帮你建立系统的索引选型能力。索引越多，写入越慢。一个表如果拥有 10 个 B-tree 索引，每次 INSERT 需要更新 10 个索引结构，写入开销可能是无索引时的数倍。原因在于：GIN 索引索引的是 JSONB 内部的键值对结构，@> 操作符直接在索引层面判断“左边是否包含右边的结构”，因此可以走索引。
2026-10-26 09:22:43
403
原创 第三篇：《数据类型详解：从 JSONB 到数组、范围、枚举》
本文从数字、字符、时间这些基础类型讲起，深入剖析 JSONB 的二进制设计、数组与范围类型的适用边界、枚举的静态约束与修改限制，并给出每个类型的“该用”与“不该用”场景，帮你从建表的第一天起就做出正确的选择。核心结论：只要你要存储的是一个“时间点”（一个事件发生的那一刻），就必须用 timestamptz。一个重要的认知：在 PostgreSQL 中，varchar(n) 和 text 的存储方式和性能完全相同——它们都是变长字符串，没有长度限制（varchar 的 (n) 只是约束，不是存储优化）。
2026-10-23 09:33:06
231
原创 第二篇：《安装、配置与 psql 高效使用》
在上一篇文章中，我们理解了 PostgreSQL 的设计哲学和适用场景。现在，是时候把它跑起来了。但安装 PostgreSQL 不只是“装一个软件”那么简单——initdb 的每一个参数、postgresql.conf 的每一项配置、psql 的每一个快捷命令，都会直接影响你未来几年的开发体验和系统稳定性。一个在安装时选错编码的数据库，可能在存储了几个月中文数据后才发现排序异常；一个没有调优 shared_buffers 的实例，可能在流量上来后把所有查询都压到磁盘上。
2026-10-23 09:23:08
202
原创 第一篇：PostgreSQL 为什么成为“最受欢迎数据库”？
答案不在“功能多”，而在它被设计成了一个可以持续生长的系统。金融债券应用需要一种“非标准”的日期运算——业务规定每月固定 30 天，即“3 月 15 日减去 2 月 15 日必须等于 30 天”，而 Ingres 实现的公历减法给出的是 28 天，客户被迫把数据拉到应用层计算再写回，效率下降两到三倍，且系统无法直接重载减法操作符。PostgreSQL 的起源：从 Ingres 的“硬编码类型系统”失败中汲取教训，Postgres 从第一天起就被设计为可扩展的类型系统，这是它四十年后仍能持续生长的根本原因。
2026-10-22 09:28:32
328
原创 第十五篇：《综合实战：构建一个代码审查 Agent 与未来展望》
在前面的十四篇文章中，我们从 Agent 的本质讲起，走过 LangChain 的核心模块、LangGraph 的状态机编排、RAG 的检索增强、MCP 的工具集成、多智能体的协作模式、安全护栏、可观测性与生产部署。完成本文后，你将拥有一个可以直接作为项目起点的完整代码库，并对 AI Agent 的未来图景有清晰的认识。从 Agent 的本质到 LangChain/LangGraph 的实战，从 RAG 到 MCP，从多智能体协作到安全、可观测、部署运维，最后以一个完整的代码审查 Agent 系统收官。
2026-10-22 09:13:50
389
原创 第十四篇：《Agent 部署与运维：从本地脚本到生产级服务》
Agent 服务与传统微服务在运维上有本质区别：Agent 的不确定性意味着“重试”可能产生不同的结果，“超时”可能意味着 Token 已经消耗但任务未完成，“扩缩容”需要基于队列深度而非 CPU 使用率。本文从“从脚本到服务”的三条部署路径讲起，深入讲解 FastAPI 封装、容器化、Kubernetes 弹性伸缩、成本控制和幂等设计，并通过一个生产级模板帮你建立 Agent 运维的完整框架。你无法用“重启”解决一个“提示词写错了”的问题，也无法用“加 CPU”解决一个“工具选择错误”的问题。
2026-10-21 09:06:48
330
原创 第十三篇：《AI Agent 可观测性与评估：追踪、调试与质量衡量》
它是 Agent 触发的执行链上的任何 span，包括下游数据库查询、第三方 API 调用、或因为 Agent 决定调用工具而运行的后台任务。Agent trace 的体量和形态——深度嵌套的 span、长时间运行的操作、分片到达的事件——对传统数据库是严峻挑战。任务完成率是二元的——完成或未完成。一个真实的 Agent 栈中，单次请求产生 10-50 个 span 是正常的，但如果没有父子结构，追踪就是一堆扁平、不可搜索的 span。传统 APM 的局限：Agent 是非确定性的、多步骤的、不透明的。
2026-10-21 09:04:51
604
原创 第十二篇：《AI Agent 安全：提示注入防护与权限控制》
提示注入（Prompt Injection）在 OWASP LLM Top 10 中连续多年稳居第一（LLM01），2026 年的 Agentic 更新又新增了“Agent 目标劫持”（ASI01） ——攻击者通过提示注入、欺骗性工具输出或投毒数据，直接重定向 Agent 的目标。本文从 OWASP 风险图谱讲起，深入解析提示注入的攻击面、检测工具链（llm-trust-guard、Anzen）、纵深防御策略，并通过一个完整的代码实战帮你为 LangGraph Agent 加上“安全护栏”。
2026-10-20 09:14:14
434
原创 第十一篇：《Agent 能力建设的完整方法论：从工具接入到自我进化》
本文从能力建设的四个阶段讲起，深入剖析 Reflexion 和 Self-Refine 的反思机制、FORGE 的群体进化协议，并通过一个完整的 LangGraph 实战帮你为 Agent 装上“自我进化”的引擎。例如，Agent 第一次调用 API 时传错了参数格式，Reflexion 会生成一条反思：“调用 create_order 时，quantity 必须是整数，不能传字符串”——这条洞察存入记忆后，下次调用时 Agent 会自动避免同样的错误。策略在循环中被更新，这就是最简形式的自我进化。
2026-10-20 09:10:05
387
原创 第十篇：《多智能体协作模式实战：协调者、竞争与流水线》
但选定了框架只是第一步——真正决定多智能体系统成败的，是协作模式的设计。本文聚焦其中三种最核心的模式——协调者、竞争与流水线——深入讲解它们的设计要点、适用场景和常见陷阱，并用 LangGraph 实现一个完整的“需求分析 → 代码实现 → 测试验证”三阶段流水线。一个真实的行研项目：资料采集用 Parallelization，任务分配用 Orchestrator-Worker，撰写用 Pipeline，质量把关用 Creator-Verifier——四种模式在不同阶段接力，这才是端到端系统的含义。
2026-10-19 09:25:15
315
原创 第九篇：《多智能体协作框架对比：AutoGen vs CrewAI vs LangGraph》
市面四个主流编排框架——LangGraph（图结构显式编排）、CrewAI（角色流隐喻编排）、AutoGen（对话流编排）、LlamaIndex Workflows（事件驱动编排）——哲学不同、抽象层级不同、适用场景不同。每个 Agent 或处理步骤是一个节点（Node） ，节点之间的流转由边（Edge） 和条件边（Conditional Edge） 控制，共享的状态（State） 在节点之间传递。不适合确定性流程：如果你需要“先做 A，再做 B，如果 C 则做 D”，对话流是错误的选择。
2026-10-19 09:20:30
336
原创 第八篇：《MCP 协议开发：为 Agent 构建自定义工具服务器》
它让 Agent 与外部工具的集成变得标准化——你写一个 MCP 服务器，所有支持 MCP 的客户端（Claude Code、Codex、Cursor 等）都能无缝接入。本文从 MCP 的核心概念讲起，深入讲解 FastMCP 框架的使用、工具/资源/提示的三大组件，并通过一个完整的自定义 MCP 服务器开发实战帮你掌握这项关键技能。MCP 的定位：为 LLM 设计的标准协议，统一 Tools、Resources、Prompts 的集成方式。MCP 服务器扩展了 Agent 的攻击面。
2026-10-16 09:58:15
146
原创 第七篇：《向量数据库选型：从 Chroma 到 Milvus 的落地对比》
本文基于 2026 年最新的基准测试数据，从性能、召回率、成本、运维四个维度，帮你建立一套清晰的向量数据库选型框架。LangChain 支持的向量数据库（部分）：Chroma、PGVector、Qdrant、Milvus、Weaviate、Pinecone、FAISS、LanceDB、Redis、Elasticsearch 等。性能基准：Qdrant 召回率最高（0.991），Weaviate QPS 最高（5,100），pgvector 成本最低（$0.08/百万查询），Chroma 最便宜但性能最弱。
2026-10-16 09:21:23
270
原创 第六篇：《RAG 实战：从向量检索到知识增强生成》
RAG（检索增强生成） 正是为解决这个问题而生的——它让 Agent 在回答问题前先检索外部知识库，基于真实文档生成答案。本文从 RAG 的核心价值讲起，深入讲解文档分块、Embedding 选型、混合检索和重排序，并通过一个完整的实战帮你构建一个基于 pgvector 的文档问答 Agent。RAG 的核心价值：在生成答案之前，先从外部知识库中检索相关文档，将文档作为上下文提供给模型，让模型基于真实信息而非训练记忆来回答问题。Agent 自主决定何时检索：不是所有问题都需要检索，让 Agent 判断。
2026-10-15 13:56:18
285
原创 第五篇：《LangChain 与 LangGraph 工程实践：从原型到生产》
在前四篇文章中，我们从 Agent 的本质讲起，走过 LangChain 的核心模块和 LangGraph 的状态机编排。一个原型 Agent 可能在你的笔记本上表现良好，但到了生产环境就会暴露出各种问题：工具调用死循环、Token 消耗失控、错误无法追踪、性能无法评估。当 Agent 陷入“调用工具 → 不满意 → 再调用 → 还不满意”的循环时，Token 会快速消耗，任务永远无法完成。但 Agent 的输出是概率性的，同样的输入可能得到不同的输出。Agent 的成本主要由 Token 消耗决定。
2026-10-15 13:50:09
384
原创 第四篇：《LangGraph 实战：用状态机构建可控的 Agent 工作流》
本文从 StateGraph 的核心概念讲起，深入讲解条件边、中断恢复和 Human-in-the-Loop，并通过一个完整的客服 Agent 实战帮你掌握 LangGraph 的编排能力。官方推荐：从 create_agent 开始快速原型，当需要更精细的控制时，下降到 StateGraph。核心原则：状态机负责确定性的流程控制，Agent 负责节点内部的理解、推理与工具调用，实现 “确定性的骨架 + 概率性的智能”。核心原则：状态机负责确定性流程控制，Agent 负责节点内部的智能决策。
2026-10-14 09:15:36
198
原创 第三篇：《LangChain 入门：模型、链、RAG 与智能体的认知地图》
好消息是，2026 年的官方路线已经非常清晰：LangChain 1.0 是核心框架，LangGraph 是编排运行时，create_agent 是智能体的标准入口。如果你搜过 LangChain 的教程，大概率会陷入混乱：有人说用 Chain，有人说用 LangGraph，有人说 create_react_agent，还有人说 AgentExecutor——这些其实都是历史遗留造成的“版本差”。关键理解：模型返回的是工具调用请求（结构化的 JSON），而非直接执行函数。执行工具是框架或你的代码的职责。
2026-10-14 09:11:23
677
原创 第二篇：《Agent 核心架构：规划、记忆与工具使用的铁三角》
它的核心思路是让模型在一个循环中交替输出“思考”（Thought）、“行动”（Action）、“观察”（Observation），然后根据观察结果继续思考，形成闭环。规划是 Agent 的“大脑中枢”。记忆是实现一致性的关键：当用户说“实际上，这是错误的颜色”时，Agent 知道“它”指的是前面讨论的项目。其他常见的规划方法还包括 Chain-of-Thought（CoT） 和 Tree-of-Thought（ToT） ，但在实际工程中，ReAct 的模式更接近真实执行场景，因为它天然对接了工具调用。
2026-10-13 09:43:16
550
原创 第一篇：《AI Agent 是什么？从 LLM 到自主智能体的演进》
整个过程是被动的、单步的、无状态的。中国工业互联网研究院在 2026 年 1 月发布的《AI Agent 智能体技术发展报告》中指出：新一代 AI Agent 正从传统的“自动化”任务执行迈向基于意图理解与环境感知的“自主性” ，成为能感知、决策、行动并学习的智能实体，其核心能力由感知、大脑、行动和记忆四大模块协同支撑。从工程实现的视角，Agent 的架构可以进一步拆解为五层：感知层（信息入口）、规划层（任务拆解与推理）、工具层（外部能力封装）、记忆层（状态存储与检索）、执行层（动作执行与反馈）。
2026-10-13 09:40:57
421
原创 第二十篇：《Codex 的未来：AI 智能体如何重塑软件工程》
这是本系列的收官之作。在过去的十九篇文章中，我们从 Codex 的诞生讲起，走过 CLI、桌面应用、IDE 插件、SDK、插件生态、MCP 协议、CI/CD 集成、批量任务、源码架构、提示词工程、模型能力、工具对比、安全边界和团队落地。开发者的核心工作不再是逐行编写代码，而是：清晰描述需求、设计任务边界、验证智能体的输出、处理智能体无法处理的异常情况。它让我们从“逐行写代码”转向“描述任务、验证结果”，从“单打独斗”转向“与 AI 协作”，从“执行者”转向“设计者”。每个智能体的输出是下一个智能体的输入。
2026-10-12 09:18:58
266
原创 第十九篇：《团队级 Codex 实践：从个人使用到组织落地》
在前面的文章中，我们掌握了 Codex 的个人使用技巧——提示词工程、批量任务、CI/CD 集成、安全边界。但当你把 Codex 从“个人工具”升级为“团队基础设施”时，会遇到一系列全新的问题：如何分配额度？如何统一代码标准？如何确保安全合规？如何衡量 ROI？OpenAI 在 2026 年 6 月推出的团队方案提供了按用量计费的 Codex 席位，但工具本身的落地只是开始。
2026-10-12 09:16:25
342
原创 第十八篇：《Codex 的局限性与风险边界：什么时候不该用它》
NVIDIA AI红队发现了Codex中的一个间接AGENTS.md注入漏洞：一个被入侵的Go库检测到Codex环境（通过CODEX_PROXY_CERT变量），写入一个恶意AGENTS.md文件，指示智能体在main函数中注入5分钟延迟，同时在PR摘要中隐藏这一变更。一项针对AI编码工具（包括Claude Code、Codex和Gemini CLI）工程缺陷的实证研究发现：超过67%的Bug与功能相关，最常见的用户报告症状是API错误（18.3%）、终端问题（14%）和命令失败（12.7%）。
2026-10-10 09:12:43
124
原创 第十七篇：《Codex vs Claude Code vs Cursor：深度对比与选型》
在AI编码工具的选择上，很多开发者陷入了一种“选择困难症”——在一个项目里反复切换工具，Cursor写了两小时代码发现跨文件重构上下文不够用，切到Claude Code处理重构很顺手但日常写代码没有Tab补全又觉得反人类，又试了Codex批量提PR，5个任务扔进去去开会，回来发现有3个PR质量还行，另外2个完全跑偏了。它们是三种完全不同的设计哲学，解决的是三类不同的问题。PR接受率：Codex全能（59.6%-88.6%），Claude Code文档之王（92.3%），Cursor修复专家（80.4%）。
2026-10-10 09:12:05
342
原创 第十六篇：《Codex 与 GPT-5-Codex 模型：底层能力与边界》
Codex 的底层模型是 GPT-5-Codex——一个专门为智能体编码优化的 GPT-5 变体。本文深入剖析 GPT-5-Codex 的架构、安全训练、基准测试表现，以及与 Claude Code 的对比，帮你建立对 Codex 底层能力的完整认知。注意：不同版本的模型（GPT-5-Codex vs GPT-5.2-Codex）和不同的评测方法会导致分数差异。GPT-5-Codex 是 GPT-5 的一个版本，专门为 Codex 中的智能体编码优化。测试任务接受率仅 59.6%：这是九类任务中最低的。
2026-10-09 09:03:40
348
原创 第十五篇：《Codex 的提示词工程：如何写出高质量的委托任务》
在前面的文章中，我们掌握了 Codex 的各种使用形态——CLI、桌面应用、IDE 插件、SDK、CI/CD 集成。但无论你使用哪种形态，与 Codex 协作的核心媒介始终是提示词。很多人把 Codex 当成一个“更强的代码聊天机器人”——描述需求、等它生成代码、跑不通再追问。这种方式能用，但不够稳定。真正的效率差异，不在于你用了哪个模型，而在于你是否掌握了委托任务的艺术。
2026-10-09 09:03:09
300
原创 第十四篇：《Codex 源码拆解：137 个 crate 构成的智能体架构》
在前面的十三篇文章中，我们从使用者的视角理解了 Codex 的方方面面——CLI、桌面应用、IDE 插件、SDK、插件、MCP、CI/CD、批量任务。但如果你想知道 Codex 的 Agent Loop 到底是怎么实现的、为什么它能高效处理复杂任务、它的状态持久化机制是怎样的，就需要深入源码。本文从整体架构讲起，逐层拆解七层架构的设计，深入剖析 Session/Turn/Step 三级模型的实现，帮你理解在 Rust 中构建 AI 智能体的工程方法论。codex-state 负责会话状态的保存和恢复。
2026-10-08 09:44:10
472
原创 第十三篇：《Codex 批量任务处理：并行委托与异步工作流》
在前面的文章中，我们掌握了 Codex 的单任务模式——你给它一个任务，它完成，你审查。但真正的效率跃迁发生在批量委托：同时把多个任务交给 Codex，让它们并行执行，你只需要在最后统一审查结果。本文从批量任务的适用场景讲起，深入讲解并行委托的实现方式、任务队列管理、质量评估与失败处理，并通过两个实战案例（批量重构 + 批量提 PR）帮你掌握 Codex 的批量工作流。批量任务最大的风险是质量波动。根据研究数据，Codex 在测试类任务中的接受率仅为 59.6%，是九类任务中最低的。
2026-10-08 09:38:22
293
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人