企业官网建设流程全解析

用 AI 写代码时，Token 账单越来越高、上下文越滚越长、回答质量越来越飘，是最让开发者头疼的事。Agentic 是一个专为 OpenCode 提供上下文工程（Context Engineering）支持的工作流工具，它靠两大核心机制帮你省 Token：任务分解（把大任务拆给多个专职子 Agent 并行处理）和新鲜上下文工作法（每个阶段都从全新会话开始，只通过文档传递信息）。本文用通俗的方式讲透这套上下文工程方法论，并附上完整的新手上手步骤。

为什么长上下文又贵又慢：AI 编程的 Token 困局

在展开 Agentic 之前，先理解它要解决什么问题：

• 成本问题：AI 每轮对话都要把整个上下文重新"读一遍"，聊天越长，每一轮烧掉的 Token 越多
• 质量下降：上下文里塞满无关的聊天记录和过期信息后，模型的推理质量会明显下滑（俗称"上下文污染"）
• 速度变慢：上下文越长，响应越慢，开发节奏被拖垮
• 知识易丢：关掉会话，之前研究过的架构细节、踩过的坑就没了，下次全得重来

Agentic 的思路很直接：别让一个大 Agent 扛所有事，也别让上下文无限膨胀。项目 README 中明确写着它的目标之一就是通过专职子 Agent 来"减少上下文窗口消耗"（Reduce context window usage through specialized subagents）。

Agentic 是什么：一条可复用的上下文工程流水线

Agentic 由三部分组成（见 README.md）：

它的开发流程被设计成一条清晰的流水线（详见 docs/workflow.md）：

📌 建 Ticket → 📚 研究 Research → 📝 计划 Plan → ⚙️ 执行 Execute → 📦 提交 Commit → ✅ 评审 Review

每个阶段都有明确的输入和产出文档，下一阶段只"读文档"，不"读聊天记录"——这正是省 Token 的关键，后面细讲。

秘诀一：任务分解——让专职子 Agent 各干各的

传统用法是"一个主 Agent 包办一切"：查文件、读代码、写方案、改代码，所有中间过程都堆在主上下文里。Agentic 的做法是把大任务分解成小任务，分发给只干一件事的子 Agent，它们干完活只把压缩后的结论交回来。

AGENTS.md 里对这种设计的描述很精准：命令借助子 Agent 完成复杂操作，"通过上下文压缩（contextual compression）最小化上下文消耗"。

6 个专职子 Agent 的分工

以研究阶段为例（流程定义在 command/research.md），命令会按定位 → 找模式 → 深度分析三个阶段编排子 Agent，同类型的 Agent 还能并行跑：

完整的 Agent 说明可看 docs/agents.md，例如 agent/codebase-analyzer.md 规定它只回答"代码如何实现"，不评价代码质量，输出必须带精确的文件和行号引用。

任务分解为什么省 Token

• 子 Agent 的探索过程（翻了哪些文件、试了哪些关键词）留在自己的小上下文里，不占用主 Agent
• 交回主 Agent 的只是结构化摘要：关键文件路径、行号、结论
• 同类型任务并行执行，还顺带省了时间

打个比方：与其让一位全能选手自己跑遍所有部门调研，不如派出一组实习生各查一个方向，最后只拿回几页汇报摘要。

秘诀二：新鲜上下文工作法——阶段之间只传文档，不传聊天记录

新鲜上下文（Fresh Context Window）是 Agentic 的第二大核心机制：每个阶段都建议开一个全新的 OpenCode 会话来执行，而不是在一个超长对话里一路做完。

docs/workflow.md 解释了原因——每个阶段从全新上下文开始可以：

• 最大化推理质量（没有无关信息干扰）
• 降低 Token 消耗
• 避免上下文污染
• 提升响应速度

那跨阶段的信息靠什么传递？答案是thoughts/ 知识库目录（结构说明见 docs/thoughts.md）：

这样设计的妙处在于：文档是"压缩过的上下文"。上一阶段花了几万 Token 探索得到的东西，被浓缩成一份带文件引用和结论的 Markdown；下一阶段的 Agent 在干净上下文里读这份文档，只花几千 Token 就拿到了同等知识。而且这些文档会留在仓库里，项目知识随时间持续积累。

💡 小细节：/review命令是少数例外——它建议在执行过 commit 的同一会话里运行，因为评审需要感知本次会话中"事情是怎么做的"。

快速上手：5 步跑通 Agentic 完整工作流

下面是新手最快配置方法（完整指南见 docs/usage.md）：

第 1 步：安装 CLI

npm install -g agentic-cli

第 2 步：把 Agent 和命令拉到项目里

cd ~/projects/my-app agentic pull

这会把agent/和command/下的配置复制到项目的.opencode目录，OpenCode 会自动识别出/ticket、/research等斜杠命令。

第 3 步起：按阶段走流水线，每阶段换新会话

1. /ticket—— 和 Agent 一问一答，把模糊想法变成结构化需求单（会自动追问边界，帮你划清范围）
2. /research thoughts/tickets/xxx.md—— 新会话中执行，产出研究文档
3. /plan—— 新会话中基于需求单 + 研究文档，交互式生成分阶段计划
4. /execute—— 新会话中按计划逐阶段实施，边做边勾选进度
5. /commit→/review—— 提交并对照计划做验收，产出评审报告

⚠️ 一个新手最该记住的原则：每个阶段的产出都要人工看一眼再进下一阶段。Agentic 官方文档特别强调，前序文档里的错误会级联放大到后续所有阶段，最终产出"不是你想要的代码"。花 10 秒审查研究文档，胜过事后花 10 分钟重做实现。

新手避坑：4 个最常见的上下文工程误区

另外三条来自官方最佳实践：给子任务指令要具体（指定目录、明确要找什么）；信任但验证，Agent 的结论要抽查实际代码；小步迭代，研究和计划都可以追问、反复打磨。

小结：把 Token 花在刀刃上

Agentic 的上下文工程方法论，归根到底是两条朴素的纪律：

1. 任务分解：大任务拆给专职子 Agent，探索过程隔离在小上下文里，主 Agent 只收压缩后的结论
2. 新鲜上下文：每个阶段从干净会话开始，靠thoughts/里的文档传递"压缩过的记忆"

省下的不只是 Token 钱，更是上下文污染带来的质量损失。这套"文档即记忆、阶段即边界"的工作法，即使你不用 Agentic，也很值得在自己的 AI 编程工作流里借鉴。