近年来，AI Agent 的能力正在快速从“会聊天”演变为“能够长期工作”。

它们开始拥有文件系统、Shell、浏览器、代码执行环境、外部 API、远程主机、数据库、记忆、插件、Skill，甚至能够把任务交给其他 Agent。

这带来了一个比“怎么写好 Prompt”更重要的问题：

当一个 AI Agent 真正开始长期运行时，它应该如何组织自己的知识、规则、上下文、记忆和工具？

如果所有内容最终都堆进一个越来越长的 system prompt，系统很快就会遇到三个问题：

• 启动上下文越来越庞大；
• 同一事实在多个地方重复，最终相互矛盾；
• Agent 很难判断哪些是事实、哪些是历史、哪些只是推断。

一个更成熟的方向，是把 Agent 看成一个长期运行的软件系统，而不是一段特别长的 Prompt。

本文讨论的正是这种演进过程。

---

一、研究 System Prompt，真正应该学习什么？

收集 OpenAI、Anthropic、Google、Microsoft、Meta、xAI、Perplexity、Cursor、OpenCode 等不同 Agent 产品的 system prompt、CLI Agent 规则和工作流后，一个很容易出现的误区是：

把优秀句子复制出来，然后拼进自己的 system prompt。

这种方法短期看起来很强，长期却很容易失控。

因为不同公司的 Agent：

• 权限模型不同；
• 工具不同；
• 上下文窗口不同；
• 产品定位不同；
• 安全模型不同；
• 运行环境也不同。

真正值得借鉴的，不是某一句具体措辞，而是多个独立系统反复出现的共同架构思想。

当这些产品横向放在一起比较时，会发现很多设计已经开始趋同。

例如：

Core Rules
    ↓
Context Routing
    ↓
Skills / Procedures
    ↓
Tools
    ↓
Execution
    ↓
Evidence
    ↓
Verification
    ↓
Durable Knowledge

这说明成熟 Agent 的核心已经不再是一个巨大 Prompt，而是一套分层知识系统。

---

二、第一原则：Bootstrap 是宪法，不是数据库

Agent 启动时会注入一部分固定上下文。

这部分内容非常宝贵。

因为启动文件中的每一个字符，都会占用正常 Session 的上下文空间。

因此最重要的设计原则之一是：

常驻 Bootstrap 应该只保存“永远需要知道的东西”。

例如：

• Agent 的基本行为原则；
• 用户授权模型；
• 安全边界；
• 如何寻找其他知识；
• 如何判断任务类型；
• 如何验证结果。

而不应该保存：

• 每台服务器的 IP；
• 每个服务的路径；
• 某个软件当前版本；
• 某块硬盘的布局；
• 某个脚本的调用参数；
• 某次维护留下的详细日志。

这些内容可能很重要，但并不需要每个 Session 一启动就全部知道。

因此，一套更健康的结构是：

AGENTS.md
→ 怎么行动、怎么授权、怎么寻找信息

USER.md
→ 用户稳定偏好

IDENTITY.md
→ Agent 是谁

SOUL.md
→ Agent 的人格与价值观

而所有环境知识都通过按需加载获得。

这相当于操作系统中的：

内核只保留核心机制，数据按需分页加载。

---

三、Context Window 本身就是一种资源

这是多个成熟 Agent 系统中非常重要、但经常被忽略的一点。

Context Window 不是无限免费的文本空间。

每加载一个无关文件、每返回一大段命令输出、每重复一次已经确认的事实，都会降低后续推理效率。

尤其是在长期 Session 中，这种影响会不断累积。

因此需要建立一个基本原则：

上下文不是越多越好，而是越相关越好。

这会直接改变知识系统的设计。

例如某台服务器可能拥有一个 30,000 字符的详细 Host Context。

用户只是问：

“这台机器当前 SSH 用什么账号？”

最差的做法是把整份 30,000 字符文档全部注入。

更合理的方式是：

先读取 Summary / Section Map
        ↓
发现 SSH 位于 Remote Access 部分
        ↓
只加载相关 section

这就是 Progressive Disclosure。

知识可以很多，但每次只加载当前任务真正需要的一层。

---

四、AGENTS 保存算法，INDEX 保存数据

早期 Agent 配置中很容易出现这样的东西：

如果是 Host A → 读取 ctx-0001
如果是 Host B → 读取 ctx-0002
如果是 Host C → 读取 ctx-0003
……

随着设备、服务、Runbook 越来越多，这张表会不断增长。

20 个 Context 尚且可以接受。

100 个呢？

500 个呢？

如果每新增一个 Context，都要往 system prompt 里增加一行路由规则，Bootstrap 就会随着知识库规模线性增长。

解决方法非常简单：

AGENTS 保存 Routing Algorithm，INDEX 保存 Routing Data。

例如：

任务提到某个 Host / Service / Runbook
        ↓
查询 context/INDEX.md
        ↓
匹配 canonical key / alias / scope
        ↓
加载对应 ctx 文件

这样即使未来存在：

ctx-0001
...
ctx-0500

AGENTS 中的路由规则仍然只有几行。

这是一种非常重要的解耦：

执行逻辑
≠
知识注册表

---

五、Context 不是 Memory

很多 Agent 系统都有 Memory。

但如果没有明确边界，Memory 最终很容易变成一个垃圾场：

机器配置
用户偏好
操作流程
历史日志
软件路径
临时结论
失败记录
账号信息
……

最后谁也不知道什么才是权威来源。

更合理的设计，是明确不同知识应该去哪。

例如：

USER.md
→ 用户稳定偏好

Context
→ 当前技术环境和长期事实

Skill
→ 可复用操作流程

output/
→ 详细审计证据和临时产物

Session Handoff
→ 跨 Session 的任务续接状态

root MEMORY
→ 只有真的找不到更合适归属的少量长期信息

如果某个事实已经有明确的 Context，就没有必要再复制到 Memory。

如果某套流程已经有 Skill，就不应该在 Memory 里再写一份。

因此一个很有价值的原则是：

Memory 不应该成为第二套数据库。

---

六、Skill 和 Context 必须分开

这是 Agent 架构中另一个非常容易混淆的地方。

可以用一句话区分：

Context 描述“这里是什么”。

Skill 描述“应该怎么做”。

例如：

某台主机上存在：
/usr/local/bin/example-sync

这是 Host Context。

但：

如何通过某套 API 管理云服务

更适合作为 Skill。

前者是环境事实。

后者是能力和流程。

如果混在一起，会出现一个常见问题：

服务器 Context 中充斥着大量 Agent 使用说明，而 Skill 中又重复保存服务器路径和运行状态。

最后两边都会过期。

清晰的分层应该是：

Context
→ 资产、路径、状态、边界

Skill
→ procedure、capability、workflow

---

七、Inquiry、Directive 和 Destructive Action 必须分开

很多 Agent 的危险并不是不会做事，而是太积极。

例如用户问：

“这个配置是不是有问题？”

用户只是要求分析。

但 Agent 发现问题以后直接开始修改。

这其实是授权模型出了问题。

因此任务应该至少分成三类。

Inquiry

例如：

• 分析
• 检查
• 审计
• 解释
• review

默认：

read-only

发现问题不代表拥有修复权限。

---

Directive

例如：

• 修复
• 修改
• 更新
• 创建
• 迁移

此时用户已经授权目标范围内的修改。

正确行为应该是：

inspect
→ execute
→ verify
→ report

而不是每一步都重新问：

“下一步可以继续吗？”

否则 Agent 会把执行责任不断转回用户。

---

Destructive / Externally Consequential

例如：

• 删除重要数据；
• 修改防火墙；
• 修改公网暴露；
• reboot；
• shutdown；
• purchase；
• public publish；
• 凭据政策变更。

如果用户没有明确授权具体动作，则必须进一步确认。

这形成了一套非常清晰的授权模型：

Inquiry
→ read-only

Directive
→ mutation within scope

Destructive
→ explicit authorization if not already granted

---

八、事实、状态和证据不是一回事

这是整个长期知识架构中最重要的设计之一。

早期 Context 很容易只有：

Active
Historical
Unknown

但这些标签回答的是：

这个资产目前是什么状态？

它们并没有回答：

为什么相信这个事实？

因此可以把知识拆成两个正交维度。

---

Asset Status

表示资产本身是什么。

例如：

Active / Current
Manual tool
Historical / Optional
Needs Verification / Unknown

---

Evidence Provenance

表示这个结论是怎么来的。

例如：

Observed
User-confirmed
Inferred
Unknown

这样就可以表达：

Status: Active / Current
Provenance: Observed

也可以表达：

Status: Needs Verification / Unknown
Provenance: Inferred

这比创造诸如：

Historical / Needs Verification
Current / consistent
Active / rebuild-critical

这种混合标签清晰得多。

一句话：

Status 回答“它是什么”；Provenance 回答“为什么相信”。

---

九、Unknown 不等于故障

这是自动化 Agent 非常容易犯的错误。

例如 Context 中出现：

Needs Verification / Unknown

Agent 很容易理解成：

“这里有问题，应该修。”

实际上 Unknown 只意味着：

证据不足。

例如：

没有确认 backup restore 是否测试过

不等于：

backup 系统故障

又例如：

发现 disabled service

不等于：

这个 service 应该 enabled

因此应该建立一个非常严格的规则：

Observed State ≠ Desired State

和：

Unknown ≠ Mutation Authorization

这两个原则可以防止大量“好心办坏事”的自动修复。

---

十、Historical 也不等于可以删除

同理：

Historical / Optional

也不代表：

safe to delete

一个历史 EFI boot entry、旧 VHD、旧 snapshot、disabled watchdog、过时 systemd unit，都可能具有恢复价值。

所以：

historical
inactive
disabled
old mtime
no caller

都不能直接推导出：

delete

删除行为必须有独立的任务目标和当前证据支持。

---

十一、Verification 不能只验证“命令跑了”

成熟 Agent 和普通自动化脚本的一个重要区别，是验证标准。

最弱的验证是：

command returned exit 0

但这只能证明：

命令自己认为执行成功。

并不能证明：

用户真正要求的目标已经成功。

例如：

systemctl status
→ active

不一定代表 Web 服务真的可访问。

HTTP 200

也不一定代表页面正常。

脚本退出 0

也不一定代表目标数据正确。

因此应该建立：

Verification Contract

例如：

修改服务
→ service active
→ port listening
→ real request succeeds

或者：

同步工具
→ command completes
→ exit code 0
→ remote discovery succeeds
→ no authentication error

PASS 必须来自用户目标对应的最终可观察状态。

---

十二、独立验证比“自己证明自己”更可靠

一个 Agent 修改代码，然后自己写一个完全基于相同假设的测试，最后测试通过。

这种证据其实很弱。

因为错误的假设可能同时存在于：

implementation
+
test

因此成熟 Agent 更倾向：

independent observable evidence

例如：

• existing test suite；
• 实际浏览器结果；
• 外部 API；
• 真实服务响应；
• golden file；
• 第二种独立检查方法。

本质上是在避免：

Agent 构造一个世界，然后证明自己构造的世界是正确的。

---

十三、失败必须有预算

Agent 的另一个典型问题是无限 rabbit hole。

例如：

方法 A 失败
→ 再试 A
→ 再试 A
→ 换参数继续 A
→ 开始扫描整个系统
→ 修改其他配置
→ 再审计
→ supplement
→ resolution
→ 再 audit

最后任务不仅没有更接近答案，反而制造了更多状态变化。

因此应该建立 Failure Budget：

同一种方法连续失败两次，而且第二次没有产生新的证据，就停止重复。

继续调查必须满足：

新的信息源
或
明确能产生额外证据的新方法

不能为了“文档闭环”制造新的工作。

---

十四、用户不应该成为 Agent 的 QA

如果 Agent 有权限测试自己的结果，却告诉用户：

“修改好了，你打开看看能不能用。”

这实际上是在把验证责任转嫁给用户。

更成熟的 Agent 应该：

修改
→ 启动
→ 实际访问
→ 验证
→ 报告

只有那些 Agent 本身无法观察的最终用户体验，才需要用户参与确认。

这一原则可以概括为：

The user is not your QA.

---

十五、并行读取，串行修改

多 Agent 带来了新的问题：并发。

多个 Agent 同时查询独立信息，通常效率很高。

但多个 Agent 同时修改同一资源，则很危险。

因此一个非常通用的规则是：

Parallelize discovery. Serialize mutation.

例如：

读取 10 个独立文件
→ 可以并行

查询几个互不相关的 API
→ 可以并行

两个 Agent 修改同一个配置
→ 禁止

共享数据库 schema 修改
→ 串行

在资源有限的本地主机上还需要进一步加一条：

多 Agent 并不意味着多重型进程并发。

Subagent 可以用于：

• 专业化；
• context compression；
• 独立调查。

但不能因为“支持多 Agent”就同时启动多个重量级模型、数据库扫描或系统诊断任务。

---

十六、Subagent 的真正价值可能是“上下文压缩”

Subagent 经常被理解成：

多找几个 AI 一起工作。

但更重要的用途其实是：

把大量低层信息压缩成主 Agent 真正需要的结果。

例如：

主 Agent
→ 派调查 Agent 阅读 50 个文件

调查 Agent
→ 返回
   - 关键事实
   - relevant paths
   - conflicts
   - unknowns

主 Agent
→ 不需要读取全部 50 个文件

因此 Subagent 本质上也可以是一种：

Context Compressor

这对于长期运行 Agent 非常重要。

---

十七、Session Handoff 应成为正式协议

长期任务经常跨 Session。

最差的方法是：

“重新把聊天历史读一遍。”

更合理的方式是建立标准 Handoff。

例如：

Task / Objective
Current State
Completed Work
Verified Facts
Decisions and Rationale
Files / Paths
Changes Already Made
Failed / Rejected Approaches
Open Questions
Hard Boundaries
Next Action

这个文件不是长期知识库。

它只是帮助下一个 Session：

从正确的位置继续。

当任务结束以后，只要真正长期的事实已经写入 authoritative Context，handoff 就可以删除。

---

十八、Evidence 和 Durable Knowledge 必须分层

详细审计结果往往非常长。

例如：

完整命令输出
systemctl status
lsblk
ip route
journalctl
Docker inspect
filesystem metadata
……

这些内容对一次审计很有价值。

但它们不适合作为每次 Agent 运行都加载的长期 Context。

因此应该分成两个层：

output/
→ Detailed Evidence

Context
→ Durable Conclusions

生命周期可以表示为：

audit
    ↓
output evidence
    ↓
分析和判断
    ↓
durable facts
    ↓
Context

并且：

output/ 应该允许删除。

这要求正式 Context 必须能够独立成立。

例如不能只写：

FRPC active.
See output/audit-xxx.md

更合理的是：

FRPC: Active / Current
Provenance: Observed
Verified: 2026-09-19

Observed:
- task running
- process present
- local dependency reachable
- external endpoint verified

最后可以附：

Detailed evidence:
output/audit-xxx.md

但 evidence 文件即使消失，Context 仍然完整。

这可以概括为：

Promote before discard.

---

十九、长期知识库必须允许“遗忘”

很多知识系统只考虑：

怎么记住更多东西？

但真正长期运行以后，另一个问题更重要：

怎么安全忘掉已经没有价值的东西？

如果什么都永久保存：

• Prompt 会膨胀；
• Memory 会变垃圾场；
• Historical information 会污染 current reasoning；
• Agent 会越来越难区分现在和过去。

因此成熟知识系统必须允许：

temporary evidence
→ delete

completed handoff
→ delete

obsolete procedure
→ archive/delete

low-value memory
→ remove

前提只有一个：

仍有长期价值的信息已经进入正确的权威层。

“会遗忘”实际上是长期知识系统成熟的重要标志。

---

二十、最终形成的 Agent 架构

经过这种设计以后，一个比较稳定的长期 Agent 可以形成如下结构：

Bootstrap
│
├── AGENTS.md
│   └── execution constitution / authorization / routing
│
├── USER.md
│   └── stable user preferences
│
├── IDENTITY.md
│   └── agent identity
│
└── SOUL.md
    └── personality and values


On-demand Knowledge
│
├── context/INDEX.md
│   └── registry
│
├── context/GOVERNANCE.md
│   └── lifecycle / provenance / verification
│
├── context/SESSION_HANDOFF.md
│   └── continuation protocol
│
├── context/active/
│   └── durable authoritative facts
│
└── Skills/
    └── reusable procedures and capabilities


Ephemeral Layer
│
└── output/
    ├── audits
    ├── evidence
    ├── migration reports
    └── handoffs

它的核心特征是：

启动很小，但知识可以无限增长。

---

二十一、真正重要的不是更长的 Prompt，而是更好的知识拓扑

研究各家公司 Agent 的 system prompt，最终得到的最大启发并不是：

“某家公司的一句话写得真好。”

而是：

最成熟的 Agent 正在逐渐从 Prompt Engineering 进入 Knowledge Architecture。

早期阶段关注：

Prompt 怎么写？

更成熟阶段关注：

什么应该常驻？
什么应该按需加载？
什么是事实？
什么是推断？
什么是流程？
什么是用户偏好？
什么应该长期保存？
什么可以删除？
什么才算真正验证？
什么时候应该停止？

当这些问题被认真解决以后，system prompt 本身反而会越来越短。

因为真正复杂的能力已经被分散到正确的层级中。

---

结语

长期运行的 AI Agent，不应该是一个知道所有事情的巨大 Prompt。

更合理的形态是：

启动时只拥有一套小而可靠的宪法，并且准确知道什么时候、去哪里、以最低的上下文成本取得权威信息。

优秀的 Agent 也不是永远记住所有东西。

它应该知道：

• 什么值得记住；
• 什么应该放在哪；
• 什么只是临时证据；
• 什么只是推断；
• 什么已经过期；
• 什么可以安全忘记；
• 什么必须重新验证。

这可能比单纯提高模型参数、扩大 Context Window 或编写更复杂的 system prompt，更接近长期 AI Agent 真正需要解决的问题。

从这个角度看，未来 Agent 的竞争也许不仅仅是“哪个模型更聪明”。

更重要的竞争可能是：

谁拥有更好的认知架构。