文章
22 篇 · 关于 AI 应用研发、Agent 系统与工程实践的笔记
01
Agent / Harness Engineering
关于 agent 记忆、工具设计、跨机协作和验证面的工程笔记。
给 agent 的记忆瘦身：常驻和按需分层
记忆越攒越多，agent 每次启动要读的东西也越来越多，最后变成「什么都记得，什么都用不上」。我的做法是把记忆分成两层：常驻层只放「我是谁、现在在干什么、最近动了什么」，加起来十几 KB；其余都是按需检索的主题文件。在我自己约 180 个记忆文件、三十多万 token 的库上，启动时实际加载从约 7 万 token 降到了几百。这篇讲分层的规则，以及哪些东西不该进常驻。
不懂 git，也能管住十几个 worktree
git 是我明确的短板：多分支、rebase、冲突、读提交图都不熟，还闯过真实的祸。但现在我同时开着十几个 worktree、几个 agent 在不同分支上干活，局面反而比以前清楚。办法不是先把 git 学透，而是让 AI 管 git，我只管几条它必须遵守的纪律，以及几个我随时能问的问题。
两个模型互审：合并前必须有第二意见
AI 写代码越快，人越审不过来。我的做法是让另一个模型来审，但评审报告本身也是一份「自述」——照单全收，等于把另一个模型的幻觉写进代码。这篇讲我在合并前加的这道「第二意见」：评审方怎么选、提示词怎么写、拿到结论后怎么逐条验证，以及几个真实踩过的坑。
让 AI 上夜班：定时任务、汇报口径和几条规矩
我用 AI 最大的变化，不是提示词写得更好，而是把它从「白天陪我对话」改成「我不在时也在干活」。一台几乎不关机的电脑上跑着十几个定时任务：凌晨体检、清晨查漂移并尝试自动修复、上班前把一夜的结果汇成一份简报。白天我只做三件事——选、看、合。这篇讲这套做法：夜班怎么排、自动修复怎么套笼子、怎么让 agent 只说重点、纠正一次怎么变成永久规则。
多 agent 并行开发：一套编排纪律
你负责定计划、裁定、验收，子 agent 负责写代码。这不是「把任务丢出去」，而是一套有纪律的编排。领地要划在共享运行时状态上而不是文件路径上；任务信必须给出理由而不只是指令；执行方最有价值的输出是「你的判断错了」而不是「做完了」。而整套里最值钱的一条是：绿色不构成证据——因为你不再亲手跑每一步，只能读报告，「看起来对」和「真的对」输出相同的风险被放大了。
一句话教你学会用 AI:写日记
AI 回答平庸不是它不行,是它不认识你——它每次开口,都是第一次见你。解法不是背提示词,是花 15 分钟建一份「我的档案」:我是谁、我要什么、我卡在哪、我的偏好。每次提问先粘档案,每周花五分钟更新。这本「写给 AI 看的日记」,就是你亲手给它装上的记忆,而且不锁在任何一家的产品里。
我把一个 git 仓库做成了「工作操作系统」——AI Coding 的两层工作流
大多数人用 AI 写代码，是把 AI 当一个更快的手。我的做法是分两层：底层用一个 git 仓库当「工作操作系统」，沉淀判断、工具和给 AI 的行为指令；上层是一天之内收集需求、AI 执行、commit 生成日报的闭环。前者管「判断怎么不跑偏」，后者管「一天怎么干完」。
我在手机上发了条指令，另一座城市的 Mac 替我部署了博客
A2A mesh 第一次跑真实生产任务：手机经 hub 把部署任务派给 Mac 上的 agent，三个节点构建、发布、验证全闭环——包括一次如实回报的失败和一次二次派单的收尾。从冒烟测试到基础设施，差的就是这一步。
用 Telegram 给多机 AI Agent 做一个可见的指挥面
当 agent 分散在多台机器上时，真正难的不是把消息发出去，而是让人能看见、能插话、能按设备路由。Telegram 的 supergroup、topics 和 bot 长轮询刚好拼出了一层轻量指挥面。
我为什么要做 Harness Engineering
AI 会写代码之后，真正稀缺的不是再会调一次 API，而是能把 Agent 放进一个可靠、可验证、可协作的工程系统里。这是我给这个 blog 定的主线。
把几台机器上的 AI Agent 连成一张能互相调用的网
我有好几台机器，每台都跑着 agent。让它们能实时互相调用，最大的拦路虎不是协议，是 NAT。这是我搭一张多设备 agent mesh 的踩坑笔记。
AI Agent 工具翻车 9 次之后：我总结的 11 条设计原则
prompt 是建议，工具实现才是合约。9 次翻车后我才想明白，AI Agent 优化的主要矛盾根本不在 AI 那一侧——是我没把世界讲对。
用 Git 给多个 AI Agent 同步一个会成长的大脑
Claude、Codex、Gemini、Hermes 跑在不同机器上，却共享同一套规则、记忆与上下文——没有插件，没有服务器，只有一个 Git 仓库。这是 nestwork 的设计笔记。
你的 Agent 应用，跑得赢大模型的进化速度吗？
大模型每升一级，就可能让你辛苦搭的 Agent 能力变成「原生开箱即用」。这是 AI 创业最核心的焦虑。我的判断是：危险的是薄薄一层包装，安全的是深深一口井。
02
职业转型与能力阶梯
在 AI 重画能力边界的这几年里，一个工程师对自己做的判断和自检。
几个月没手写一行代码，我怎么衡量自己的产出
我已经几个月没手写过一行代码了，所有代码都由 AI 生成，用同一个 git 身份提交。这让旧的衡量方式全部失真：提交数大部分是机器的，代码行数更说明不了什么。我换了一套尺子——只看交付物，只问流向不问辛苦，把「验、收、推、合」当成真正的瓶颈来管。这篇讲这套尺子，以及它逼着我承认的几件事。
技术贬值时代的转型方向——从执行位挪到判断位
「99% 岗位 3-5 年被 AI 替代」这个前提一半对一半错，而错的那一半恰好决定了转型方向。真正贬值的不是技术，是按工时出售的执行；真正需要的也不是换方向，是换位置。
从前端到 Harness Engineering：我给自己定的三年方向
一个以前端为主的全栈工程师，为什么把长期方向押在「为 AI Agent 设计能力边界」这件还没几个人在做的事上。
人类相对 AI 的净优势——筛掉那些已经守不住的
别再用「AI 取代不了人的温度」这种话安慰自己。我试着把人类相对 AI 的优势项一条条筛一遍，把守不住的划掉，看看真正剩下什么。
AI 会写代码了，非科班还要补 CS 基础吗？
我是半路出身的全栈，AI 能帮我写一大半代码。那还有必要回头补计算机科班的基础吗？我的答案是：有必要，但要挑重点。
AI + Agent 时代，程序员的能力阶梯
AI 会写代码之后，程序员的价值不再是「会敲」，而是沿着一条能力阶梯往上走——从会提问，到会定义问题。这是我画的两张阶梯。
03
独立产品实验
小工具、内容系统和真实付费场景的产品取舍。