cmzznet的博客

AI Chat 产品的竞争点不是把消息发给模型，而是能否把用户意图、文件、工具结果和记忆组织成可执行上下文。本文拆解上下文工程的消息、文件、工具、记忆四层设计。

上周我清一个内容发布脚本链路，发现一个很小但很烦的现象：脚本本身只有几十行，package.json 里却要挂一串运行器。tsx 一个，ts-node 一个，typescript 一个，CI 镜像里还要多跑一次安装。真正的业务逻辑是读 Markdown、算摘要、调浏览器发布，结果启动成本先被工具链吃了一口。

上周我排一个 Agent 执行链路的问题，日志里有一行特别刺眼：模型把「检查依赖」理解成了「重装依赖」，生成了一条 rm -rf ./node_modules && npm install。

—这件事过去是 QA 团队 3 个人配合两个小时的工作量。我没装这个扩展跑过（只对 Plus / Pro / Business / Enterprise 等套餐开放，且需要 macOS 桌面端 Codex），所以这篇是。

系列收官篇。前四篇拆了会话控制、上下文管理、记忆、工具执行。但还有一层没有显式画在架构图里，却横跨所有层——**模型路由**。用一个模型跑所有任务，要么太贵（全用旗舰），要么质量不够（全用便宜的）。这篇讲怎么在 Harness 里设计智能路由，让每个任务自动跑在最合适的模型上。

系列前三篇覆盖了总览、上下文管理、记忆层。这篇聚焦第 4 层——工具执行。这一层通过 MCP 协议把模型连接到外部世界，也是安全风险最集中的一层。三个核心工程问题：工具装多少合适、安全怎么做、怎么动态加载

系列第一篇拆了 5 层总览，第二篇深入了上下文管理。这篇聚焦第 3 层——记忆。上下文管理处理的是"当前 session 内的信息"，记忆层处理的是"跨 session 的知识持久化"。这一层决定了你的 Agent 是一个"每次见面都忘了你是谁的陌生人"，还是一个"记得你偏好和历史的助手"

本文从工程角度深入分析了Agent Harness的五层架构设计及其对模型表现的影响。通过类比CPU与整机的关系，说明Harness作为模型运行环境的重要性。五层架构包括：会话控制层（连接管理和触发机制）、上下文管理层（规范注入和窗口策略）、记忆层（跨会话知识持久化）、工具执行层（安全调用外部工具）和输出通道层（结果交付）。文章指出，Harness的设计质量直接影响模型20-40%的性能表现，并分享了关键设计决策，如防竞态连接管理、上下文摘要策略、工具数量优化等实战经验。这些工程细节决定了AI代理能否稳定运

微软于4月3日发布了生产级开源框架Agent Framework 1.0，支持.NET和Python双语言，内置MCP和A2A协议，可一键切换6大模型厂商。相比LangChain的链式组合，MAF采用编排优先设计，内置Sequential、Group Chat和Magentic-One三种协作模式，特别适合多Agent协作、.NET集成及本地模型场景。其原生支持跨语言Agent通信和任务分解的Magentic-One模式，是企业级AI应用的高效解决方案。

2026 年 4 月，海外开发者社区出现了一个新词叫"Sleep-Driven Development"——下班前把任务丢给 AI Agent，Agent 通宵干活，早上起来 Review PR。这不是玩笑，多个团队已经在生产环境中这么做了。这篇拆解背后的技术方案和坑。

Anthropic 最近把 Claude 的官方 Prompt Engineering 指南做了一次大更新，专门为 Opus 4.7 新增了十几个小节。我通读了一遍，挑出 7 条最实用但中文社区几乎没人提过的建议。

AI Agent 生态里目前有三个标准在抢地盘：Anthropic 的 MCP（9700 万次安装）、Google 的 A2A 协议、OpenAI+Google 联推的 AGENTS.md。很多人搞不清它们的关系——是竞争还是互补？我从官方文档和架构层面拆解一下，附选型建议。

社区天天讨论哪个模型 SWE-bench 分高、哪个代码能力强。我做了一个对照实验：固定模型不变，只改变它的运行环境（Harness），代码质量差了 3 倍。决定 AI 编程效果的不是模型，是 Harness。

更要命的是，Skill 里引用的编码规范改了一版，但 Skill 文件没人更新，新来的同事照着旧 Skill 写了三天代码，全部返工。第一步做什么，第二步做什么，分支条件是什么，全部预定义好。它的劣势也在这里——一旦遇到预定义之外的情况，要么报错，要么走兜底，不会自己想办法。朋友的团队上个月做了一件事：把他们积累的二十几个"好用的 Prompt"整理成文件，放进仓库，统一命名，叫 skill-xxx.md。但一个真正的 Skill，不只是说明书——它是一个完整的能力单元，包含规则、上下文和工具。

AI 不会消灭软件工程，它只会消灭低维的软件工程

本文探讨AI时代下软件工程的结构性变革。作者发现，尽管AI使代码产出提升3倍，但交付速度仅提高20%，揭示当前工程体系与AI能力不匹配的问题。文章提出"AI-Native软件工程"概念，指出工程师角色正从代码编写者转变为系统设计者和AI调度者，工程核心转向意图定义、系统设计和AI协作规划。作者认为真正的突破在于重构工程结构，而非仅使用AI工具，并预告将通过实践案例继续探讨这一转型。这标志着软件工程正从"人写代码"向"AI执行系统"的根本转变。