前两篇讲了用 AI 做计划的心法和工具，但都有个漏洞：PDCA 是个环，却全靠人手动推着转，人一忙就停。这篇讲怎么用一个长期运行的 AI Agent 把 Check→Act→Plan 半环自动转起来——它不替你干活，它是个不睡觉的监工，盯进度、发提醒、起草方案，卡住了就喊人。

上一篇讲了用 AI 做计划的心法，这篇讲兵器：有哪些 AI 工具能落地 PDCA，通用工具怎么选，怎么把 PDCA 封装成你自己的 AI Skill——文末附一份可以直接抄的 Skill 模板和四段 Prompt。

凡事预则立，不预则废。可做计划往往费力不讨好，跟踪、纠偏更是耗时。这篇讲讲怎么把管理学、心理学里那些做计划的老经验，跟 AI 结合起来，让 AI 帮你把 PDCA 环转起来——你省下的时间，用来创新创造。

把 tinyhumansai 开源的 OpenHuman clone 下来读了一遍——一个纯 Rust 内核 + Tauri 桌面的开源 AI 助手。它把"AI 助手"拆成了三件事：一块会按时给自己喂料、压缩成"记忆树"的持久记忆大脑；一个跑在可恢复图（tinyagents）上的编排器，能把一群子代理当成一支舰队来指挥；外加一整套从语音、会议、工作流到加密的 agent 间通信的家当。真正让我放下的是它的取舍：复杂的 ML 全外包给开源 crate，内核只负责"对与错"的调度与安全，隐私开关一到 Rust 层就直接掐死出网。这篇按代码讲讲它这套"会折腾的剥洋葱式"架构，以及一个老后端能从中抄走的东西。

“铁打的营盘流水的兵”和“英雄造时势”，这两句话在办公室里天天打架。我在国企、外企、私企都待过，兜了一圈的体会是：这道题的分界线不是行业，而是这块活的主要风险到底是“做错”还是“做不出来”。这篇给一个能上手的分类——护栏、记忆、仪式，解释为什么大企业的流程只会变多不会变少，一个改不了流程的普通人怎么用 AI 改掉自己和流程之间的那层界面，以及为什么“AI 替代人”只说对了一半：等、盯、催、填可以交出去，想、选、扛只能自己留着。

拆 i365dev 开源的 free4chat——一个"开房间就能说话、不注册不存数据"的实时语音文字聊天室。真正让我感兴趣的不是功能，而是它为了"不养服务器"这个目标换了三次技术栈：Go+Pion、Elixir+Membrane，最后落到 Cloudflare 全托管（RealtimeKit + Workers + Durable Object）。这篇按代码讲清楚它现在的架构：Worker 只发一个短期 token，媒体走 WebRTC 数据面，两小时房间过期、三层反机器人，以及那个藏在 Durable Object 里的 AI 助手 Luna，还有它踩过的坑和留给自己的下一步。

“超级个体”这个词被讲了太多遍，多半落在“一个人干十个人的活”。我作为一个写了半辈子代码、又被推着做点项目管理的老兵，让 AI 写代码当然也用，但真正想让它接走的是那些不想干又不得不干的活：走流程、开会、跟进度、要支持、写各种报告。这篇拆开讲：哪些活能交、哪些活死也交不出去，秘书型 AI 的五项职能，三段式落地路径，两个从头到尾走完的例子（带 deadline 的待办清单、例行周会），以及别人已经跑通的案例和我踩过的坑。

Anthropic 那篇《Building Effective Agents》我隔一阵就翻一遍，每次读都有点新体会。这篇是我第 N 次重读后的笔记：先把 workflow 和 agent 掰扯清楚，再把五种 workflow 模式和真正的 agent 逐个过一遍，重点讲什么时候该用、什么时候别用，最后落到一张选型表和一份落地清单。核心就一句话——别一上来就上 agent，能用简单模式解决的，绝不加复杂度。

2026-07-28 版 MCP 规范被官方称为"发布以来最大的一次改动"：协议核心从有状态改成无状态，握手和 Session Header 被砍掉，长任务、UI、鉴权都拆成了扩展。这篇先用大白话讲清楚这次到底改了什么、为什么改，再用一个"高德天气 MCP Server"的 Python 实例带你上手。

边车（sidecar）和主服务跑在同一个 Pod 里，只隔着一层内核，却常常还在用 localhost:8080 这种"绕远路"的方式通信。这篇把同机通信的三条主流路子——HTTP over TCP、gRPC、以及走 Unix Domain Socket（UDS）——的技术细节、延迟、吞吐、序列化开销和运维成本摊开对比；并专门讨论迁移成本最低的 HTTP over UDS 及其双向通信短板，给出 SSE / WebSocket / gRPC over UDS 三档解法。最后附一张选型表和落地清单，帮你在真实场景里选对那条最短的路。

mTLS + 证书绑定令牌很安全,但浏览器和 App 里没法优雅地管客户端证书。DPoP(RFC 9449)就是为公网客户端准备的那把锁:客户端自己生成一对公私钥,每次请求都附上一个用私钥签名的 DPoP proof。本文把 DPoP 的每个字段、两段流程、防重放机制和常见坑一次讲透,并回答“服务间调用要不要用 DPoP”,顺带讲清 SPIFFE JWT-SVID 的定位。

Bearer Token 最大的毛病是“谁捡到谁能用”。本文用大白话讲清两个专治盗用的概念——PoP（证明我是令牌的主人）和 Certificate-Bound Token（令牌只认这张证书），顺带把它们跟 mTLS、DPoP、Kubernetes、SPIFFE 之间的关系理顺。

微服务之间到底该怎么互相证明“我是谁、我能干什么”？本文借 AWS STS 的思路，拆开临时凭证的门道，对比 JWT+OIDC 与 AWS 式 AssumeRole 两条路线，并给出可以直接跑起来的最小实现。

写了大半辈子技术文档，我一直用“教程 + 例子 + FAQ”那一套教别人用 API/SDK，后来又加了 AI skill，可还是不够直观。这篇聊聊我的反思：AI 时代的软件教程，应该是可交互、可执行、有 AI 随时答疑纠错的“活教程”——sandbox 演示 + 类 Notebook 的边看边跑 + AI 助教，能把市面上大多数静态教程甩开一条街。

为什么 Claude Code、Codex 这些编码 Agent 感觉比“裸模型”聪明得多？秘密不在模型参数里，而在模型外面那层叫 Harness 的壳。这篇翻译并解读 Lilian Weng 2026 年 7 月的长文《Harness Engineering for Self-Improvement》：什么是 Harness、三大设计模式、优化路线图（上下文工程→工作流→自我改进→进化搜索→权重联合优化）、七大未来挑战，以及我作为一个后端老兵的解读。

MySQL 的锁是很多线上事故的“隐形主角”——超卖、死锁、慢查询拖垮整个库，往往都能追到锁上。本文从并发下为什么需要锁讲起，把 InnoDB 的全局锁、表锁、MDL、行锁、间隙锁、Next-Key Lock 一层层拆开，再用 Metrics-Driven Development 的方式定义业务、应用和数据库指标，演示如何发现、定位、改进和验证锁问题，最后讨论 MySQL、Redis、ZooKeeper/etcd 分布式锁的边界。

一份可实操的 AI Infra 自学路线——包含六阶段的知识地图、每阶段的推荐资源、动手实验和验收标准，附带完整的练级手册 Checklist，让后端工程师按图索骥，3~4 个月转型 AI Infra。

与其一个个手搓专业 AI Agent，不如造一台"孵化器"——一个父 Agent，听你一句大白话，就快速孵化出贴身服务某类需求的子 Agent。这篇聊聊这台"AI Agent 制造工厂"的运转机制：父 Agent 怎么把自然语言编译成五份产品图纸（角色/工具/规矩/提示词/验收），照着标准模板批量生产，再让子 Agent 用 ReAct 边想边做。以日程安排专家作为流水线上的第一个样品。

把 K8s 集群想成一座城：apiserver 是市政大厅，etcd 是档案馆存着所有户口和钥匙，kubelet 是每个街区的物业管家。攻击者很少一步登天，更多是从一个不起眼的 Pod 开始，一格一格往上爬，直到拿到"城主令牌" cluster-admin。这篇借 ControlPlane 与 Kubernetes 官方安全审计的威胁模型，用 STRIDE 逐个拆解核心组件的风险，再画一棵"从一个 Pod 打到集群管理员"的攻击树，最后给一份能照着做的加固清单。

我以前有位高级 QA 老同事：每次 Design Review 之后，她都会拿出一整套验收用例，没通过就别把软件包交给她。如今我们已经不是同事，我却把她的质量纪律“蒸馏”成了 qa-acceptance-harness，并配上 lazy-harness-audit 和 lazy-harness-helper：先定义什么叫做对，再用证据验收、审计和改进 AI 编码护栏。