Agent-Workflow on Armstrong Yan

我做了一个小型 Harness，防止 AI 编程项目丢失状态

Tue, 21 Jul 2026 09:21:48 +0800

AI 编程智能体很强大。

但项目一旦拉长，往往会在一些非常具体的地方出问题：

会话突然中断
上下文越积越长
每周额度耗尽
第二天接手的智能体忘了前一天做过哪些决定
智能体改动了无关文件
工作明明还没完成，智能体却提前宣布结束

问题不在于 AI 不会写代码。

真正的问题是，AI 编程项目往往没有持久的项目状态。

所以，我做了一个小型开源模板：

ai-agent-harness-template

它的目标很简单：

让 AI 编程项目随时都能恢复并继续推进。

这不是提示词合集链接到标题

现在已经有很多实用的提示词合集。

但这个模板不是。

它是一套仓库级 Harness，专门用于需要长期推进的 AI 编程项目。

适用工具包括：

Codex
Claude Code
Cursor Agent
其他类似的编程智能体

不过，它不依赖任何一家厂商。

控制边界就是仓库本身。

核心思路链接到标题

应该把智能体当作无状态工作进程来用。

它们不该依赖聊天记录。

每次开始工作时，都应该根据仓库文件重新建立上下文。

这个模板把持久状态保存在以下文件中：

SPEC.md：保存需求
feature_list.json：保存可执行的功能状态
progress.md：保存恢复工作所需的记录
AGENTS.md：保存智能体规则
QUALITY.md：保存评估标准
runs/：保存证据和交接记录

这样一来，后来接手的智能体、人工维护者和 CI 都以同一份信息为准。

仓库现在还提供了一个可安装的 AI Agent Harness skill。

这个 skill 不是另一套数据库。

它只是同一套仓库状态协议的便捷入口。

真正持久的记忆依然留在仓库里。

为什么聊天记录不适合充当数据库链接到标题

聊天记录可以提供有用的上下文。

远程智能体工作流

Tue, 21 Jul 2026 09:03:39 +0800

这个系列探讨如何从移动端 SSH 走向一套以代码仓库为依托、可以长期运行的 AI 智能体工作流。

起因很简单：离开 Mac 后，我仍然想继续推进本地的 Codex 工作。

但随着实践深入，问题很快变成了：

怎样才能把远程访问转变为一套可恢复、可验证、可以长期运行的智能体工作流？

系列文章链接到标题

远程智能体工作流（一）：用手机连接 Mac 运行 Codex
借助 Tailscale、SSH、Termius、tmux 和 caffeinate，打通手机到 Mac 的终端连接。
远程智能体工作流（二）：从远程 Shell 到智能体控制面
解释为什么移动端 SSH 虽然是实用的基础设施，却不适合充当长期智能体任务的日常操作界面。
远程智能体工作流（三）：把 Telegram 变成本地 Codex 的控制面
让 Telegram Bot 以轮询模式运行，把它变成一个轻量的移动端控制界面，用手机就能指挥本地 Codex 任务。
远程智能体工作流（四）：在仓库中，而非聊天中
让代码仓库同时承载智能体记忆、运行约定，并成为 Agent Harness。
远程智能体工作流（五）：Codex Mobile 之后，什么依然重要
官方 Codex Mobile 推出后，重新审视这套自建工作流：它不是替代品，而是项目侧的工作流适配器。

核心演进路径链接到标题

远程终端
 -> 远程运行环境
 -> 移动端控制面
 -> 仓库记忆
 -> 基于仓库的 Agent Harness
 -> 工作流适配器

目的并不是证明哪一种界面更好。

远程智能体工作流（五）：Codex Mobile 之后，什么依然重要

Mon, 20 Jul 2026 23:52:52 +0800

这是“远程智能体工作流”系列的第五篇。

最初搭建这套远程 AI 开发环境时，我想解决一个很实际的问题：

离开 Mac 以后，怎样让本地 Codex 继续干活？

于是有了第一层方案：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

后来我发现，手机上的 SSH 不适合充当日常操作入口，于是又搭了一个 Telegram 控制面：

手机 -> Telegram Bot -> 本地 Codex 运行时 -> 指定代码仓库

再往后，我意识到背后还有一条更根本的原则：

放在代码仓库里，不要放在聊天里。

代码仓库必须保存持久的项目记忆。

更准确地说，它应该承载项目记忆、运行约定和反馈机制。

走到这一步，一个很自然的问题随之而来：

既然官方已经推出 Codex Mobile，自定义远程智能体工作流还有必要吗？

我的答案是：有。但理由变了。

它的价值不再只是让人远程接入 Codex。

更重要的是让 Codex 按照项目自己的方式工作。

Codex Mobile 解决了什么链接到标题

2026 年 5 月 14 日，OpenAI 宣布在 ChatGPT 移动应用中以预览形式推出 Codex。

通过官方移动端，用户可以随时在手机上接入 Codex。按照 OpenAI 的介绍，你可以跨线程处理任务、检查输出、批准命令、切换模型、发起新任务，还能实时收到终端输出、差异内容、测试结果、截图和审批请求等更新。

远程智能体工作流（四）：在仓库中，而非聊天中

Mon, 20 Jul 2026 23:33:28 +0800

这是“远程智能体工作流”系列的第四篇。

我的远程 AI 开发环境，第一层解决连接问题。

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

有了这条链路，我可以用手机访问 Mac，也能让耗时较长的本地任务持续运行。

第二层解决控制问题。

手机 -> Telegram Bot -> 本地 Codex 运行时 -> 选定的仓库

这样一来，手机就成了控制入口，而不再是一台屏幕很小的终端。

但这两层都没有触及更深的问题。

远程访问让我能连上机器。

远程控制让我能启动任务、查看进展。

而长时间运行的智能体开发还需要记忆。

智能体可能在我离开后继续运行，也可能从中断处恢复、换一个会话接着做，或者由我通过手机操控。既然如此，整个项目就不能只存在于一条聊天线程里。

于是，我给自己定了一条规则：

聊天用来传达指令。
仓库用来保存记忆。

更准确地说，仓库不只是存放代码的地方。它还承载着智能体的记忆和操作约定，并为智能体提供持续的反馈机制。

为什么聊天记录不能充当项目状态链接到标题

聊天很适合表达意图。

我可以在聊天里说明目标、提出问题、纠正方向，或者做出产品决策。

但要长期保存项目状态，聊天并不可靠。

聊天内容难以比较差异，也不便验证；它依附于某一条线程，后续会话中的智能体很容易误解，甚至根本看不到。想法、日志、猜测、决定和已经过时的背景信息，往往全都混在同一条信息流里。

如果只是一次性的小改动，这样做未尝不可。

可一旦智能体需要长时间工作，问题就会暴露出来。

项目必须能稳定回答以下问题：

这个系统应该做什么？
哪些内容已经实现？
以前在哪里失败过？
什么证据能证明这些行为现在仍然正常？
下一个智能体在修改文件之前，应该先读什么？

这些答案应该和代码放在一起。

让仓库同时承担记忆与 Agent Harness 链接到标题

在我的项目里，智能体需要长期保留的状态通常分散在以下文件和记录中：

AGENTS.md
SPEC.md
feature_list.json
progress.md
test_plan.md
init.sh
orchestrator.py
git 历史

文件具体叫什么并不重要，重要的是分清职责。

远程智能体工作流（三）：把 Telegram 变成本地 Codex 的控制面

Mon, 20 Jul 2026 23:20:13 +0800

这是「远程智能体工作流」系列的第三篇。

前两篇文章里，我先搭出了一条实用的远程终端链路：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

有了这条链路，我就能可靠地从手机连接自己的 Mac。

但新的局限很快就暴露出来：手机并不好用来操作终端。

移动端 SSH 适合救急，但我不想靠它处理需要长时间运行的 AI 开发任务。我不想在狭窄的手机屏幕上敲 shell 命令、连接 tmux 会话、翻找长篇日志，再一点点拼凑出当前状态。

我真正想要的，是下面这样的链路：

手机 -> 任务式接口 -> 本地智能体运行时 -> 仓库状态

于是，我做了一个小型 Telegram Bot，把它用作本地 Codex 的控制面。

关键不在于 Telegram 有多特别。

真正重要的是：手机成为控制界面，而 Mac 仍然负责执行工作。

为什么选 Telegram 链接到标题

Telegram 很适合用来做这个实验，因为它已经具备：

移动端通知
简短的命令消息
回复串
内联按钮
跨设备历史记录
成熟的 Bot API

更重要的是，Telegram 支持两种截然不同的部署模式。

第一种是 webhook 模式：

远程智能体工作流（二）：从远程 Shell 到智能体控制面

Mon, 20 Jul 2026 22:33:24 +0800

这是“远程智能体工作流”系列的第二篇。

上一篇文章里，我搭建了一套实用的远程终端工作流：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

这套方案解决了第一个问题：离开书桌后，怎样连回自己的 Mac；手机断开后，怎样让本地智能体继续执行耗时较长的任务。

它很快就派上了用场。

但在实际使用后，我又发现了第二个问题。

SSH 解决了连通性，却不会自动带来一套好用的远程开发工作流。

移动端 SSH 用得越多，它的边界就越清楚：

手机不该被当成一台微型终端。
手机应该成为本地智能体工作流的控制面。

第一层解决的是基础设施链接到标题

远程终端这套配置仍然不可或缺。

我需要：

用 Tailscale 连接手机与 Mac，又不把 SSH 暴露在公网上。
用 SSH 安全登录。
用 tmux 保证耗时较长的任务不会因连接断开而终止。
用 caffeinate 防止 Mac 在智能体工作期间休眠。

这样，我就有了一套可靠的基础能力：

我可以连上机器。
我可以启动工作。
我可以断开连接。
我可以稍后再连回来。

这是很实在的一步。

但它只回答了基础设施层面的问题：

我能连到这台机器吗？

它没有回答工作流层面的问题：

我能顺畅地用手机推动耗时较长的 AI 开发工作吗？

对我来说，答案是否定的。

手机并不是一台好终端链接到标题

移动端 SSH 很适合应急访问。

AI 原生软件工程（四）：氛围编程无法取代人的判断

Sat, 18 Jul 2026 23:53:44 +0800

实现可以自动化，评估也可以自动化。但判断，始终只能由人来做。

这是“AI 原生软件工程”系列的第四篇。

本文接续上一篇：AI 原生软件工程（三）：软件即搜索。

第一篇追问，我们如何形成理解。

第二篇追问，我们如何获得正确性。

第三篇提出，软件正在变成一种搜索过程。

但有一个危险的误解，必须说清楚：

只要有智能体、验证框架和约束，
软件就能自行生产出来。

事实并非如此。

在第二篇里，约束帮助我们获得正确性。

在第三篇里，约束塑造了实现方案的搜索过程。

这一篇要继续追问：谁来为约束本身负责？

谁来决定该优化什么，
该拒绝什么，
又有哪些东西从一开始就值得做？

开始采用 AI 辅助的软件开发流程后，我注意到一个出乎意料的现象。

实现能力越强，判断反而越有价值。

起初，我觉得这有些反常。

AI 越强，人的决策不应该越不重要吗？

结果恰恰相反。

实现不再是瓶颈。

方向才是。

氛围编程：好用，直到失控链接到标题

大多数开发者都经历过这样的过程。

一开始，你只有一个简单的想法：

把 X 做出来。

AI 生成代码。

你稍作调整。

跑通了。

于是继续往下做。

一个个小胜利不断累积。

项目也渐渐变大。

直到某个时刻，问题突然一股脑冒了出来：

架构渐渐偏离原来的方向
抽象层越堆越多
调试越来越慢
对系统的信心彻底崩塌

系统依然能运行。

但已经没人说得清，它为什么能运行。

项目陷入一种奇怪的状态：

好像一切都能推倒重来。

却没有任何东西真正处于掌控之中。

我把这叫作氛围编程。

并不是因为 AI 不好。

而是因为，每一步进展都不再对应一个经过认真权衡的决定。

测试通过带来的错觉链接到标题

面对这种问题，一个常见的回答是：

多加一些测试就好了。

我也这样做过。

AI 原生软件工程（三）：软件即搜索

Sat, 18 Jul 2026 23:37:09 +0800

当实现变得唾手可得，工程就不再那么像建造，而更像导航。

这是“AI 原生软件工程”系列的第三篇。

本文承接上一篇：AI 原生软件工程（二）：验证框架工程与正确性。

第一篇追问：

当实现工作交给 AI 后，理解从何而来？

第二篇追问：

当生成的成本变得低廉，如何保证正确性？

这一篇要问：

如果实现越来越便宜，
工程师究竟在做什么？

在这里，约束的含义发生了变化。

第二篇谈约束，是为了保证正确性。

这一篇谈约束，是为了界定搜索范围：

如何划定可接受实现的范围？

纵观软件发展史的大部分时期，开发软件就意味着把它建造出来。

先有一个想法。

然后设计架构。

接着编写实现。

最后测试结果。

瓶颈显而易见：

写代码。

我们对工程能力的理解，也一直建立在这个前提之上。

人们眼中的优秀工程师，往往能够：

更快写出实现
更快完成调试
熟记更多 API
精通更多框架
交付更多可以运行的代码

AI 正在动摇这个前提。

不是因为它会取代工程师。

而是因为它让实现成本骤降。

一旦实现变得便宜，软件开发的方式也会随之改变。

它开始变得像一场搜索。

传统工程：在实现稀缺时做建造链接到标题

传统的软件开发大致遵循这条路径：

想法
-> 架构
-> 实现
-> 验证

实现的代价很高。

每个决定都要付出成本。

每一层抽象都至关重要。

改变方向非常痛苦，因此人们会在动手之前优化方案。

工程就是建造。

AI 让建造变成探索链接到标题

有了现代编程智能体，实现不再稀缺。

短短几分钟，你就可以得到：

五种架构
三套重构方案
两种数据库模型
多套 API 设计

于是，工作流程变成了：

AI 原生软件工程（二）：验证框架工程与正确性

Sat, 18 Jul 2026 23:29:59 +0800

在 AI 原生软件工程中，最重要的也许不是生成，而是约束。

这是「AI 原生软件工程」系列的第二篇。

本文承接上一篇：AI 原生软件工程（一）：智能体编程中的心智模型。

上一篇讨论的问题是：

如果理解系统不再主要依靠亲手写代码，
人类要如何在智能体工作流中建立心智模型？

接下来的问题是：

如果实现工作交给了 AI，
正确性从何而来？

谈到 AI 辅助软件开发，人们往往只关心一件事：

我们能将软件产出提高多少？

编码更快。

上下文更长。

智能体可以自主运行。

一次改动多个文件。

工作流能够自我修复。

但用 AI 智能体做了一段时间项目后，我却得出了相反的结论：

最重要的工程问题，不是如何让 AI 更自主。

而是如何更严格地约束 AI。

因为毫无限制地生成代码，几乎从来不是瓶颈。

正确性才是。

这里暂且不谈约束对创造力或搜索空间的影响，只谈正确性。

真正要回答的是：

怎样才能让 AI 生成的实现可以被放心信任？

传统软件开发的基本假设链接到标题

传统软件开发建立在一个简单的假设上：

人
-> 实现
-> 验证

写系统的人，也会在动手实现的过程中逐渐理解系统。

很多时候，验证并不会被单独提出来。

因为实现出自自己之手，你自然更愿意相信它。

在小团队中，这套做法出人意料地管用。

直到复杂度不断攀升。

AI 打破了这个假设链接到标题

智能体编程改变了原有结构。

现在，整个循环变成了：

人
-> 意图
AI
-> 实现
人
-> 审查

乍看之下，效率很高。

AI 原生软件工程（一）：智能体编程中的心智模型

Sat, 18 Jul 2026 22:57:49 +0800

AI 能生成代码。验证框架能检验行为。但理解由谁来建立？

这是“AI 原生软件工程”系列的第一篇。

这个系列想追问一个更大的问题：

当 AI 降低了实现成本，
软件工程中还有什么是稀缺的？

本文先从第一种稀缺资源谈起：

理解。

过去几个月，我一直在密集尝试 AI 辅助的软件开发方式。

不是自动补全。

也不只是把 AI 当作编程副驾驶。

而是一套由智能体主导执行的工作流：

SPEC
-> 约束
-> 验证框架
-> 智能体执行
-> 评估
-> 迭代

这段经历非常有意思。

借助它，我用自己并不十分熟悉的语言和框架交付了项目，开发速度也大幅提升。

做小项目时，简直像魔法。

可一到更大的项目，意想不到的情况发生了。

我发现，实现速度和系统理解并不是一回事。

最后，我不得不面对一个让人不太舒服的事实：

如果 AI 明天消失，
我可能很难继续开发自己系统里的某些部分。

这个认识改变了我看待软件工程的方式。

传统模式：在实现过程中形成理解链接到标题

过去的软件工程，大致是这样的：

人
-> 编写代码
-> 建立心智模型
-> 运行和维护系统

写代码不只是为了实现功能。

它也是学习系统的过程。

我们在这些事情中逐渐弄懂系统：

调试
重构
追踪执行过程
与各种约束周旋
犯错

亲手实现，自然会带来理解。

只是过去，我们未必意识到这一点。

智能体编程改变了路径链接到标题

有了 AI 编程，整个循环变了。

Agent-Workflow on Armstrong Yan

我做了一个小型 Harness，防止 AI 编程项目丢失状态

这不是提示词合集 链接到标题

核心思路 链接到标题

为什么聊天记录不适合充当数据库 链接到标题

远程智能体工作流

系列文章 链接到标题

核心演进路径 链接到标题

远程智能体工作流（五）：Codex Mobile 之后，什么依然重要

Codex Mobile 解决了什么 链接到标题