很多人在使用 Agent 编程时关注的问题是Agent 能不能完成任务但是当项目从一次性任务变成长周期开发时一个更基础的问题出现了Agent 启动以后应该先看什么传统程序启动时会加载配置和依赖。Agent 进入项目时也需要先加载项目说明、当前任务和项目状态。如果没有这个启动过程Agent 就只能凭当前看到的文件猜测哪里可以改哪里不能改当前任务到底做到哪一步哪些问题以前已经处理过。这时它看起来像是在工作实际上是在陌生项目里摸索。所以复杂项目需要一个简单的 Agent 启动协议。它的作用不是让 Agent 立刻写代码而是先告诉 Agent进入这个项目后应该按什么顺序理解项目。一、传统程序有 mainAgent 也需要入口传统程序有明确的执行入口intmain(){...}程序从 main 开始运行。但一个项目没有天然的 Agent 入口。项目里可能有很多文件README.md src/ docs/ tests/ config/ logs/ issues/人类开发者大致知道这些文件的含义README 介绍项目代码实现功能测试验证结果日志记录变化。但 Agent 不一定知道应该先读什么。它可能先打开代码文件也可能先读 README也可能直接根据用户的一句话开始修改。对于小任务这样问题不大但对于长期项目这很容易导致范围扩大、重复修改甚至破坏已经验收通过的部分。因此项目需要一个给 Agent 使用的启动入口。这个入口可以称为Agent 启动协议。二、启动协议不是知识库而是加载顺序Agent 启动协议不需要保存所有项目知识。它更像一个启动菜单告诉 Agent先加载哪部分认知再加载哪部分任务最后进入执行。例如可以在项目中定义一个文件agent_bootstrap.md这个名字不是行业标准而是项目自己的约定。它可以这样写# Agent 启动协议 ## 阅读顺序 1. project_map.md 了解项目目标和结构。 2. current_task.md 了解当前任务和验收标准。 3. state.md 了解当前状态。 4. open_issues.md 了解未解决问题。 5. revision_log.md 了解历史修改原因。 ## 工作规则 - 不扩大当前任务范围。 - 不随意修改已验收模块。 - 修改后更新状态。 - 遇到不确定问题先确认。这个文件本身不是知识库。它不负责回答所有问题只负责告诉 Agent去哪里找到正确的问题。这就是启动协议的价值。三、不同 Agent 有不同入口项目也要有自己的入口需要注意agent_bootstrap.md是项目自己的约定。不同工具有不同规则。有的工具读取自己的配置文件有的工具读取规则文件有的工具通过系统提示加载项目说明。以 Codex 为例可以在项目根目录放一个它能识别的文件AGENTS.md然后在里面写# Codex 项目入口 在处理本仓库任何任务之前必须先读取 ./agent_bootstrap.md 读取后按照其中定义的顺序理解项目、确认任务、执行修改和更新状态。 如果 agent_bootstrap.md 不存在先停止并提醒用户。这样就形成了两层入口AGENTS.md ↓ 告诉 Codex 先读什么 agent_bootstrap.md ↓ 定义项目自己的启动协议一句话AGENTS.md是 工具入口agent_bootstrap.md是项目的启动协议。工具入口可能随平台变化但项目启动协议应该尽量稳定。四、启动协议加载的是项目的几张“卡”可以把 Agent 想象成一个通用机柜。LLM 像一颗通用 CPU里面有大量知识也有很强的生成能力。但它还不是一台具体机器。真正决定它进入什么工作状态的是项目给它插入的几张 .md 卡。不同的 Markdown 文件就像不同的功能卡project_map.md ↓ 项目认知卡 current_task.md ↓ 当前任务卡 state.md ↓ 当前状态卡 revision_log.md ↓ 历史经验卡 open_issues.md ↓ 风险问题卡这些卡片组合起来才让一个通用 Agent 变成当前项目里的工作成员。如果插入的是论文修改相关文件它就更像论文修改 Agent。如果插入的是程序维护相关文件它就更像代码维护 Agent。如果插入的是 Figma 还原规则、视觉验收标准和组件状态它就更像网页还原 Agent。所以 Markdown 文件不是普通说明文档。它们是 Agent 启动时加载的项目边界。五、md 文件约束不是越多越好Markdown 文件能帮助 Agent 理解项目但并不是越多越好。如果把 LLM 近似看作一个巨大的候选解空间那么prompt 给出求解方向Markdown 文件给出边界条件验收机制负责筛选结果。边界太少Agent 会乱跑边界太多Agent 会被框死边界互相冲突Agent 会在几个不兼容的方向之间来回跳。例如要求一严格复现 Figma。 要求二不能修改现有 CSS 结构。这两个要求单独看都合理。但如果现有 CSS 结构本身无法支撑 Figma 的设计那么这两个条件就可能没有交集。这时 Agent 就会表现为改好这里那里又坏修好按钮布局又乱越改越像在原地打转。这不一定是模型不会做也可能是人给出的求解空间本身被切裂了。因此启动协议不是让 Agent 一次性读取所有文件而是让它加载刚好足够的边界。AI 渐进编程不是让 Markdown 文件越来越厚而是让每一轮加载的上下文足够清楚、足够短、足够可执行。六、启动协议让 Agent 从临时工具变成项目成员没有启动协议时Agent 像临时工具。它看到一个问题就修一个问题看到一个需求就扩展一个需求。但它不一定知道项目的整体方向当前任务的边界哪些部分已经验收哪些历史问题不该重复处理。有了启动协议以后Agent 才更像项目成员。它先加载项目认知再确认当前任务然后读取状态最后进入执行。这个过程不是为了增加形式感而是为了减少猜测。Agent 缺的不是信息而是启动时加载正确上下文的机制。七、从 Prompt 工程到 Agent 工程早期 AI 编程关注的是如何写一句更好的 prompt但复杂项目中真正的问题已经不只是一句话而是Agent 从哪里开始它应该读取什么它如何知道当前状态它如何避免重复犯错它如何继承过去经验它如何知道什么算完成这些问题已经超出了 prompt进入了 Agent 工程。过去的软件项目主要给人看所以有README.md。Agent 时代项目还需要让智能体知道我应该如何开始工作。以 Codex 为例一个项目可以同时拥有三类入口README.md ↓ 给人理解项目 AGENTS.md ↓ 给 Codex 找到工具入口 agent_bootstrap.md ↓ 定义项目自己的启动协议这不是简单增加几个文档而是项目结构正在发生变化。未来的软件项目不仅需要代码结构也需要智能体结构。结语Agent 的第一步是正确启动长期项目中Agent 不只是要完成任务还要以正确方式进入项目。如果启动时没有加载项目认知、当前任务和项目状态它就只能凭局部信息猜测如果启动过程清楚它就能更快进入上下文减少重复犯错并把结果写回状态。AI 编程正在从一次性 prompt走向可持续的 Agent 工作流。而 Agent 的第一步就是正确启动。