迪图
发布于 2026-10-20 / 11 阅读
1
0

从 Prompt 到 Agent:AI 应用工程的四级台阶

从 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

可靠性

  • 工具调用必须带指数退避重试(最多 3 次)

  • 高影响动作需置信度阈值判断,低于阈值走人工确认

  • 不可逆步骤设验证门(validation gate)

第四级:上下文工程

这是 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 架构)

  • [ ] 有明确的规划层,不靠模型自由发挥

  • [ ] 工具描述清晰,工具数量克制

  • [ ] 有最大步骤数限制

第三级(工程化)

  • [ ] 完整执行轨迹可查(输入/输出/token/延迟)

  • [ ] 黄金集评测接入了 CI

  • [ ] 成本按功能追踪,有预算告警

  • [ ] 不可逆操作有验证门

第四级(上下文工程)

  • [ ] system prompt 稳定,前缀可缓存

  • [ ] 历史上下文有压缩策略,且永不丢约束

  • [ ] 长任务有外部笔记机制

  • [ ] 定期检查:是否在无脑堆上下文

参考资料

  • 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


评论