一、长时间运行，不是一次思考很久#

我最初容易产生一种错觉：Agent 接到任务后，会像人一样维持一段连续而稳定的思考，从头推演到尾，然后把答案一次性做出来。

真实过程更接近很多个短闭环：

1
观察当前状态
2
    ↓
3
决定一个小动作
4
    ↓
5
执行动作
6
    ↓
7
读取真实结果
8
    ↓
9
验证是否取得进展
10
    ↓
11
更新状态并重新决策

也就是：

1
Observe → Think → Act → Verify → Repeat

比如 Agent 要修复一个登录超时问题，它不会只在脑中推演完整答案。它可能先搜索报错文本，找到调用链，读取相关配置，运行一个目标测试，观察失败，再修改一个函数，然后重新运行测试。每一步都不大，但每一步都会从环境中获得新的事实。

因此，所谓“自主运行两个小时”，并不是一次 LLM 调用持续两个小时，而可能是数百次这样的循环。只要系统能够保证：

1. 每一轮仍然知道最终目标；
2. 每一轮知道当前真实状态；
3. 每一轮都能从上一步结果继续；
4. 失败后能够恢复而不是失忆；

短循环就可以连接成长任务。

Agent 的长期能力首先是一种系统能力，而不是“思考时间”更长。

二、第一件重要的事：把目标变成完成条件#

用户给出的需求往往是模糊的：

1
帮我给登录接口增加限流。

这句话没有说明哪些行为算完成、能否改变现有接口、要不要增加基础设施、如何处理并发，以及应该用什么证据证明实现有效。

如果 Agent 只记住一句自然语言目标，很容易在长时间执行中发生漂移：修着修着开始重构认证模块，顺便升级依赖，最后代码改了很多，却没有真正完成用户要的事情。

成熟的系统需要把目标展开成一份任务契约：

1
目标：
2
为现有登录接口增加失败限流。
3

4
约束：
5
- 不改变外部 API；
6
- 不引入新的基础设施；
7
- 保持旧配置兼容；
8
- 不修改无关模块。
9

10
验收条件：
11
- 同一用户连续失败 5 次后受到限制；
12
- 限制持续 10 分钟；
13
- 正确密码不能绕过限制；
14
- 对应单元测试通过；
15
- 全量测试没有新增失败；
16
- lint 和类型检查通过。

从系统角度看，这是在定义一个谓词：

1
Done(current_state) = true / false

只要 Done 仍然为 false，任务就不应该因为“已经写了不少代码”而结束。

这也是目标管理和普通待办列表的差别。待办列表只记录做过什么，目标管理还要不断追问：

• 这些动作是否真的缩小了目标差距？
• 原来的完成条件是否仍然成立？
• 新发现是否要求调整计划？
• 当前结果是“看起来完成”，还是已经有证据证明完成？

长任务能够不偏航，靠的不是模型永远记性很好，而是总目标和完成条件会被反复带回决策过程。

三、真正的记忆，是外部化的任务状态#

上下文窗口再大，也不适合承担全部长期记忆。

聊天历史混合了用户要求、模型推理、命令输出、失败尝试和大量已经过时的信息。运行时间越长，真正重要的目标越容易被淹没；一旦上下文压缩、进程中断或模型切换，纯粹依赖对话历史的任务也很难准确恢复。

因此，Agent 会把关键状态外部化。逻辑上可以理解为：

1
Task State
2
├── 原始目标
3
├── 当前验收条件
4
├── 不可违反的约束
5
├── 当前计划
6
├── 已完成子任务
7
├── 正在处理的子任务
8
├── 未解决问题
9
├── 已修改文件
10
├── 最近验证结果
11
├── 已知风险
12
└── 下一步候选动作

例如：

1
[完成] 复现登录超时
2
[完成] 确认问题来自连接池耗尽
3
[完成] 添加回归测试
4
[进行] 调整连接释放逻辑
5
[待办] 运行认证模块测试
6
[待办] 执行全量回归
7
[风险] Windows 下有一个既存测试不稳定

这里保存的不是一篇冗长总结，而是继续工作所需的最小世界状态。

这带来几个直接好处：

• 上下文被压缩后仍能恢复目标；
• 中途失败后不需要从头调查；
• 用户插入新要求时可以判断它改变了什么；
• 每一步的进展、证据和风险都有明确位置；
• 系统能够发现重复劳动和无效循环。

所以，Agent 的 Memory 不应该只理解为“记住用户以前说过什么”。对于长任务，更重要的是保存此刻世界是什么状态，以及距离目标还差什么。

四、上下文工程：不是给得越多越好#

一个真实仓库可能有几十万行代码。把全部文件一次性塞进上下文，不仅昂贵，还会产生严重的注意力污染。

好的 Coding Agent 更像一名刚接手项目的工程师，采用渐进式调查：

1
读取项目结构与规则
2
    ↓
3
定位相关模块
4
    ↓
5
搜索符号、调用者和测试
6
    ↓
7
阅读少量关键文件
8
    ↓
9
根据新发现继续扩展范围

模型每轮真正需要看到的，通常只是一个工作集：

1
当前目标
2
+ 当前子任务
3
+ 项目规则
4
+ 相关代码
5
+ 最近修改
6
+ 测试或命令反馈
7
+ 必要的任务状态

这里的关键不是“上下文越长，Agent 越强”，而是：

在正确的时刻，把完成下一步所需的最小、最新、最可信的信息交给模型。

文件搜索、语言服务器、Git 历史、测试结果、项目文档乃至编译器报错，都是外部记忆的一部分。Agent 不必始终记住整个仓库，只需要知道如何重新找到事实。

上下文工程还需要区分信息的寿命：

• 项目规范、用户约束属于长期稳定信息；
• 当前计划和修改范围属于任务级信息；
• 一次命令输出和一个局部报错属于短期信息；
• 已经被证明错误的假设应该退出活跃上下文，但保留在失败记录中。

如果不做这层治理，长上下文只会变成一间堆满旧草稿的办公室。

五、任务分解：目标稳定，计划可变#

复杂任务需要计划，但计划不能被当成不可修改的剧本。

在尚未阅读代码之前，Agent 不可能准确知道所有实现细节。如果一开始生成二十个步骤，然后机械执行到底，后续发现的真实情况就无法影响路线。

更合理的是分层规划。

战略层保持稳定：

1
1. 理解现状
2
2. 复现问题
3
3. 确定修改边界
4
4. 实现最小修复
5
5. 验证局部行为
6
6. 完成全局回归
7
7. 审查风险

阶段层围绕当前任务展开：

1
当前阶段：复现问题
2

3
1. 找到相关测试
4
2. 确认实际调用链
5
3. 构造最小复现
6
4. 记录修改前行为

动作层则尽量小：

1
运行 tests/auth/test_timeout.py

执行后，Agent 根据真实结果重新判断。测试路径可能不存在，问题可能已经修复，根因也可能与最初假设完全不同。这些都应该触发重新规划。

所以，一个可靠 Agent 的行为模式是：

1
目标稳定
2
计划动态
3
动作短小
4
证据驱动

计划的作用不是预测未来的每个细节，而是维持方向、暴露依赖、控制工作范围，并为下一步决策提供结构。

六、工具系统：模型只有提议权，系统掌握执行权#

没有工具，模型只能生成文本。有了文件读取、代码搜索、编辑、终端、浏览器、Git 和外部服务，Agent 才能感知并改变环境。

但 Tool 并不只是给 LLM 暴露几个函数。

一套真正的工具系统至少要回答：

• 模型此刻可以发现哪些能力？
• 每个工具在什么情况下使用？
• 输入参数如何校验？
• 调用会读取或改变哪些资源？
• 是否允许执行，是否需要用户批准？
• 超时、部分成功和结果未知如何表达？
• 输出怎样保持紧凑、稳定、便于模型继续判断？
• 调用如何记录和审计？

模型生成的 Tool Call 本质上只是一个行动提议：

1
LLM 提议动作
2
    ↓
3
系统校验参数
4
    ↓
5
策略层检查权限与风险
6
    ↓
7
在受限环境中执行
8
    ↓
9
返回结构化结果
10
    ↓
11
LLM 根据结果继续决策

工具返回“命令执行成功”也不等于用户任务成功。例如文件写入成功，只能证明写文件这个动作完成了，不能证明写入内容正确；部署接口返回 200，也不能证明线上服务健康。

Tool 是 Agent 的手和眼睛，但目标判断仍然属于更上层的执行循环。

七、高质量来自验证闭环，而不只来自生成质量#

普通代码生成常常停在：

1
我认为这段代码应该可以工作。

Coding Agent 需要走到：

1
我用与任务匹配的证据验证了它确实工作。

典型验证链条包括：

1
语法检查
2
→ 格式化
3
→ 静态分析
4
→ 类型检查
5
→ 单元测试
6
→ 集成测试
7
→ 构建
8
→ 运行时验证
9
→ Diff 审查
10
→ 验收条件复核

不同任务需要不同证据：

真正可靠的路径不是：

1
生成 → 完成

而是：

1
生成
2
→ 验证
3
→ 发现差距
4
→ 定位原因
5
→ 修改
6
→ 再验证

这其实是一个 evaluator–optimizer 循环：一个过程产生候选结果，另一个过程按照明确标准寻找差距，然后继续优化。

验证还必须尽量独立于“我刚刚写了什么”。如果 Agent 只运行自己新增的测试，或者通过降低断言强度让测试变绿，就会出现自我证明。已有测试、编译器、运行时行为、外部接口和最终 Diff，构成了相互补充的证据。

八、为什么不容易把整个项目改崩#

任何 Agent 都无法保证绝对不破坏项目。可靠性来自多层防线，而不是一次完美判断。

1
修改前：1268 passed，3 failed
2
修改后：1269 passed，3 failed

九、检查点、失败分类与恢复#

长任务一定会失败。命令会超时，依赖会下载失败，测试会卡住，最初方案会被证明错误，模型调用也可能中断。

如果系统把所有失败都当成同一种失败，只会出现两个极端：遇到错误立刻放弃，或者无休止重试。

更成熟的方式是分类处理：

1
临时错误：
2
网络抖动、服务暂时不可用
3
→ 有限次数重试
4

5
可修复错误：
6
编译失败、类型错误、测试失败
7
→ 分析反馈并修改
8

9
路径错误：
10
设计假设不成立、方案造成连锁回归
11
→ 回到检查点并更换方案
12

13
权限错误：
14
需要访问额外目录、联网或执行高风险动作
15
→ 暂停并请求批准
16

17
目标错误：
18
需求冲突、关键业务选择无法推断
19
→ 保留现场并请求用户决策

检查点则为恢复提供锚点：

1
Checkpoint 0：原始状态与基线
2
Checkpoint 1：问题已复现
3
Checkpoint 2：回归测试已建立
4
Checkpoint 3：核心修复完成
5
Checkpoint 4：全量验证通过

某条路径进入死路时，系统可以保留调查成果，但丢弃错误实现，从最近的正确状态继续，而不是在错误基础上不断打补丁。

还需要防止无效循环：

1
同一个错误连续出现多次
2
→ 停止重复原动作
3
→ 总结已尝试方案
4
→ 检查假设
5
→ 换路线或升级给人

长任务能力的本质不是永远不犯错，而是犯错之后能够识别、止损、保留有效进展并继续推进。

十、安全靠能力边界，而不是一句 Prompt#

在系统提示中写“不要执行危险命令”是有帮助的，但不构成真正的安全边界。

LLM 是概率性决策器，它可能误解命令，也可能低估动作的影响。安全必须在模型之外被强制执行：

1
模型提出动作
2
    ↓
3
策略引擎判断风险
4
    ↓
5
允许 / 拒绝 / 请求批准
6
    ↓
7
受限环境执行

动作可以按风险分层：

1
低风险：
2
- 读取项目文件
3
- 搜索代码
4
- 在工作区内做局部修改
5
- 运行本地测试
6

7
中风险：
8
- 联网下载依赖
9
- 修改大量文件
10
- 改变项目配置
11
- 访问工作区之外的目录
12

13
高风险：
14
- 删除重要目录
15
- 使用生产凭证
16
- 修改线上数据
17
- 部署生产环境
18
- 推送受保护分支

Sandbox 决定 Agent 能触达哪些资源；权限策略决定哪些动作可自动执行；审批把关键决定交还给用户；审计日志则回答“谁在何时，以什么理由，执行了什么”。

真正的安全目标不是要求 Agent 永远做出正确判断，而是：

即使某一次判断错了，它也没有足够的能力造成不可控损失。

这是一种 capability security：控制能力，而不是依赖模型“自觉”。

十一、Hook：把必须发生的事交给确定性程序#

有些工作需要理解和权衡，例如判断根因、选择修改方案、决定下一步调查什么。这些适合交给 LLM。

另一些规则不需要推理，只需要稳定执行：

• 修改 Python 文件后必须格式化；
• 提交前禁止包含 .env；
• 修改 Schema 后必须生成迁移；
• 结束前必须执行目标测试；
• 高风险命令执行前必须检查策略。

如果只是把这些规则写进 Prompt，模型仍然可能因为上下文过长或注意力变化而忘记。

Hook 会在确定的生命周期节点自动触发：

1
文件修改后 → formatter
2
命令执行前 → 风险检查
3
准备提交前 → secret scan
4
任务结束前 → 测试与验收检查

这背后是一条很重要的工程原则：

1
需要语义理解、探索和权衡的事 → 交给 LLM
2
必须稳定发生、规则明确的事   → 交给程序

一个好的 Agent 系统不会把所有责任都压给模型。恰恰相反，它会尽量把确定性部分从模型手里拿出来。

十二、多 Agent 的真正价值#

Planner、Coder、Tester、Reviewer、Security Agent 看起来很强大，但“Agent 数量更多”并不自动带来更好的结果。

多 Agent 主要有三个实际价值。

1
先建立可靠的单 Agent 闭环
2
→ 再识别可以隔离或并行的子问题
3
→ 明确输入、输出、权限和验收标准
4
→ 最后才增加 Agent

十三、四个嵌套循环如何组成完整 Agent#

把前面的设计放在一起，可以把成熟 Coding Agent 抽象为四层循环。

1
最终要达到什么状态？
2
当前距离目标还有什么差距？
3
是否已经满足全部验收条件？

1
下一项子任务是什么？
2
依赖是否满足？
3
计划是否需要调整？

1
读取什么？
2
调用什么工具？
3
修改什么？
4
执行结果是什么？

1
这个动作是否允许？
2
是否需要审批？
3
执行前是否需要检查点？
4
失败后应该重试、回退还是暂停？

1
while not goal_satisfied:
2

3
    refresh_world_state()
4
    task = choose_next_task()
5

6
    while not task_satisfied:
7

8
        context = gather_relevant_context()
9
        action = decide_small_reversible_action(context)
10
        permission = evaluate_risk(action)
11

12
        if permission_requires_human:
13
            pause_for_approval()
14

15
        checkpoint_if_needed()
16
        result = execute(action)
17
        evidence = verify(result)
18

19
        if evidence_confirms_progress:
20
            update_task_state()
21
        elif error_is_recoverable:
22
            retry_or_replan()
23
        else:
24
            rollback_or_escalate()
25

26
    evaluate_global_goal()

十四、从控制论看 Coding Agent#

到这里，我觉得理解 Coding Agent 最贴切的方式，不是“一个会自主写代码的聊天机器人”，而是一个反馈控制系统：

一个差的 Agent 接近开环控制：

1
收到目标 → 生成大量代码 → 希望它正确

一个好的 Agent 则是闭环控制：

1
收到目标
2
→ 执行一点
3
→ 测量结果
4
→ 比较目标差距
5
→ 修正方向
6
→ 再执行一点
7
→ 直到误差足够小

这也解释了为什么 Coding Agent 看起来能够处理远超单次生成能力的复杂任务。它不是一开始就知道完整答案，而是能够借助真实环境，一边行动，一边获得证据，一边纠偏。

十五、真正精妙的地方：让“不可靠”变得可用#

抛开模型能力后，Agent 设计最精妙的地方，并不是隐藏了某个神奇 Prompt，而是做了大量看似朴素的工程工作：

• 用明确验收条件约束目标；
• 用外部状态抵抗遗忘与中断；
• 用按需检索保持上下文准确；
• 用动态计划适应未知环境；
• 用小步行动降低错误影响；
• 用真实验证替代模型自信；
• 用检查点和分类恢复处理失败；
• 用 Sandbox、权限和审批限制破坏；
• 用 Hook 保证确定性规则必然发生；
• 用多 Agent 隔离上下文、权限和独立工作。

这些机制叠加在一起，才让一个概率性模型能够稳定工作很久。

可以把整体可靠性粗略理解为：

1
Agent 可靠性
2
≈ 模型能力
3
× 目标清晰度
4
× 上下文质量
5
× 工具质量
6
× 验证强度
7
× 状态恢复能力
8
× 安全边界

它更像乘法，而不是加法。任何一项接近零，整体体验都会明显崩塌。

所以评价一个 Coding Agent，不应该只看它一次能生成多少代码，也不应该只看它接入了多少工具、拥有多少个子 Agent。更值得观察的是：

• 它如何定义任务完成；
• 如何在长时间运行中保持目标；
• 如何获取此刻真正需要的上下文；
• 如何证明每一步产生了有效进展；
• 如何区分失败并恢复；
• 如何限制高风险行为；
• 如何证明最终结果可信。

我现在更愿意这样理解 Coding Agent 的“自主”：

高级感不来自它可以不受控制地运行很久，而来自它自主运行很久以后，结果仍然围绕目标、可以验证、能够解释，并且在出错时可控、可停、可恢复。

这不是一次性推理的胜利，而是反馈控制、软件工程与模型能力共同作用的结果。

本文部分内容与整理由 Codex 协助完成，并结合作者自己的理解整理。