从 Prompt 到 Agent:AI 应用工程的四级台阶
Vibe Coding → Agent 架构 → 工程化 → 上下文工程。这是 2026 年 AI 应用的四个递进台阶,也是新团队最常搞混顺序的地方。
开篇:一个常见的失败顺序
很多团队的路径是这样的:
第一周:用 Claude 写了个 Prompt,效果不错 ✓
第二周:接了几个工具,变成 Agent ✓
第三周:需求变复杂,Agent 开始跑偏 ✗
第四周:发现是上下文管理的问题,回去调 Prompt ✗
第五周:反复打补丁,越来越脆弱 ✗
问题不在于哪一步做错了,而在于跳过了「上下文工程」这一级。
模型在商品化,上下文工程在差异化。两个团队用同一个 Claude 做同一款 Agent,效果差 3 倍——差的从来不是模型,而是谁把上下文调度得更聪明。
四级台阶对照
台阶 | 核心问题 | 你在做什么 |
|---|
Vibe Coding | 怎么让 AI 写代码 | 用自然语言换取产出 | Agent 架构 | 怎么让 AI 自主行动 | 引入循环、工具、状态 | 工程化 | 怎么让 AI 可复用、可运维 | 可观测、可测试、成本可控 | 上下文工程 | 怎么让 AI 在长任务中不翻车 | 策展每一轮进入窗口的内容 |
这四步是递进的,跳级必然付出代价。 第一级:Vibe Coding核心:把重复的编码劳动交给 AI,快速获得产出。 解决的问题:样板代码、CRUD、单元测试、脚手架。 局限: 生成后你必须真的读懂,否则技术债累积 上下文窗口一满就"失忆" 无法处理跨十几个文件的复杂改动
到此为止,这就是"用一个很厉害的聊天框"。 第二级:Agent 架构从"AI 回答一次"变成"AI 完成任务"。 三个转折点转折一:ReAct 循环(2022-2023) 模型的输出从"直接回答"改成"推理 → 行动 → 观察"循环。Agent 从"只读文本"变成"可以操作世界"。 转折二:规划与记忆分离(2023) Planner 负责拆解任务,Executor 负责执行,Memory 负责跨会话。长任务可控性大幅提升。 转折三:多智能体协作(2023-2024) 不同专长的 Agent 分工协作。LangGraph 等框架把协作流程从"自由对话"变成"可编程的状态机"。 详见Agent 架构的五种设计模式与选型决策,见《AI Agent 架构设计模式:从 ReAct 到多智能体协作》。 这一级的典型问题症状 | 根因 |
|---|
Agent 半路"忘了"任务目标 | 没有规划层,或规划被后续噪声淹没 | Agent 反复调用同一个工具 | 工具描述不够清晰,或没有"已完成"状态 | 多 Agent 互相矛盾 | 子 Agent 各自持有部分上下文,世界观不一致 | Token 消耗失控 | 没有步骤上限和成本护栏 |
这些问题里,超过一半的根因是上下文问题,而不是架构问题。 这就是第四级存在的意义。 第三级:工程化从"能跑"到"能上生产"。 可观测性Agent 必须记录完整执行轨迹。每一步至少: 时间戳 | 节点名称 | 输入 | 输出 | Token 用量 | 延迟
推荐工具:LangSmith、Langfuse、Arize Phoenix。 没有轨迹的 Agent,无法调试。 而 Agent 的调试难度是普通代码的数倍——因为控制流有一部分藏在模型的决策里。 评测从"我觉得效果不错"到可度量的指标。 层级 | 方法 | 用途 |
|---|
检索层 | Recall@k、MRR | RAG 是否召回了正确文档 | 生成层 | Faithfulness、Answer Relevancy | 回答是否基于上下文、是否切题 | 任务层 | 任务完成率 | Agent 是否真的完成了事 | 业务层 | 转化率、人工满意度 | 是否真的产生价值 |
黄金集 50-200 条真实用例,每次改动跑 CI —— 这是最可靠的工具。 成本护栏Agent 的 Token 消耗是单次对话的 10-100 倍。 措施 | 说明 |
|---|
步骤上限 | 硬限制最大步数,防止无限循环 | 模型分层 | 简单子任务用小模型 | Prompt Caching | 复用稳定前缀 | 成本追踪 | 按功能、按用户追踪 token |
可靠性第四级:上下文工程这是 2026 年真正的护城河。 为什么这一级最重要上下文是有限资源。
Attention 是稀缺资源。
"塞满窗口" ≠ "用上窗口"。
Lost in the Middle:模型对长上下文中段的信息利用率显著下降,规模化场景退化可达 40%。 Context Rot:Chroma 测试 18 个模型(含 Claude Opus 4、GPT-4.1、Gemini 2.5 Pro、Qwen3),固定任务难度、只变输入长度,所有实验性能一致下降。 四个动词动词 | 做什么 | 一句话 |
|---|
Write(写穿) | 关键状态写到外部,主上下文留指针 | 别什么都记在脑子里 | Select(选择) | 只拉当下需要的 | 按需加载,不要一次全塞 | Compress(压缩) | 摘要化旧内容,保留关键决策 | 压缩的第一原则是永不丢约束 | Isolate(隔离) | 脏活分给独立上下文的子 Agent | 主线程只收结论 |
成本账这是上下文工程最硬的存在理由: 项目 | 数据 |
|---|
1M token 窗口的价格跨度 | $0.14 – $10.00(71 倍) | 缓存命中折扣 | Gemini 约 1/4,DeepSeek 约 1/10 | 上下文工程综合降本 | 50-90% |
这比换模型更大的杠杆。 一条判断标准每一层都要回答:"这个信息为什么值得占用主上下文?" 答不上来,就把它移到窗口外。 如何判断你在哪一级症状 | 你在第几级 | 该做什么 |
|---|
Prompt 改来改去效果不稳定 | 第一级 | 引入规划和状态管理 | Agent 长任务中途跑偏 | 第二级 | 加规划层,明确步骤 | Agent 跑起来了但没人知道它做了什么 | 第二级 | 补可观测性 | 能监控了但成本超预算 | 第三级 | 加成本护栏和模型分层 | 模型换代了还是跑偏 | 第四级 | 做上下文工程 | 长对话越来越水,开始胡编 | 第四级 | 压缩 + 隔离 | 多 Agent 互相矛盾 | 第四级 | 检查上下文共享策略 |
团队该按什么顺序投入1. 先把「评测」建起来
└── 没有度量,后面全是猜
↓
2. 再把「可观测性」补上
└── 看不见轨迹,调不动
↓
3. 然后做「上下文工程」
└── 这是收益最大的一步
↓
4. 最后考虑「换更强的模型」
└── 这是最容易被迷信的杠杆
顺序反了就会变成:不断换模型,每次都稍好一点点,但问题始终存在。 一个反直觉的结论上下文工程会让应用层消失,但不会让问题消失。 阶段 | 变化 |
|---|
现在 | 开发者手写压缩、缓存、选择逻辑 | 演进中 | 这些变成推理框架的内建能力(auto-compaction 已出现) | | |
| 未来 | "上下文工程师"这个头衔消失,但它管理的东西变成和数据库连接池一样的基础设施 |
|---|
当它成为常识的那天,区别一个 AI 应用好坏的又会回到最原始的问题:你对用户的事情,到底懂多少。
上线前的分级检查清单
第一级(Vibe Coding)
[ ] 生成的代码你真的读过了
[ ] 技术债有记录
第二级(Agent 架构)
[ ] 有明确的规划层,不靠模型自由发挥
[ ] 工具描述清晰,工具数量克制
[ ] 有最大步骤数限制
第三级(工程化)
第四级(上下文工程)
参考资料
Anthropic, *Effective context engineering for AI agents* — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
LangChain, *Context Engineering for Agents* — https://blog.langchain.com/context-engineering-for-agents/
Chroma, *Context Rot*(2025-07)— https://research.trychroma.com/context-rot
Liu et al., *Lost in the Middle*(TACL)— https://arxiv.org/abs/2307.03172
Manus, *Context Engineering for AI Agents* — https://manus.im/blog/context-engineering-for-ai-agents
Cognition, *Don't Build Multi-Agents* — https://cognition.ai/blog/dont-build-multi-agents