Prompt Engineering

从本质上讲，Prompt 就是对概率分布的“条件约束”。由于 LLM 包含了海量的人类知识，如果不加限制，它预测的下一个词是发散的。

prompt 的作用就是画一个圈，把 LLM 的注意力限制在特定的语境、角色或任务中，从而提高期望输出的概率。

发展演进

阶段一：Zero-shot（零样本）
- 做法：直接问“北京的首都是呢？”
- 痛点：模型完全靠直觉（预训练权重）回答，遇到复杂问题容易胡说八道
阶段二：Few-shot（少量样本/上下文学习）
- 做法：在问题前加上几个例子（Q:1+1, A:2; Q:2+2, A:?）
- 演进原因：人们发现 LLM 有强大的模式模仿能力，给它看例子，它能瞬间学会当前需要的输出格式和逻辑
阶段三：Chain of Thought（CoT，思维链）
- 做法：在 prompt 中加入魔法咒语：“请一步一步地思考”
- 演进原因：LLM 倾向于直接给出答案（复杂任务往往是错误的），CoT 的本质是 LLM 把生成的中间过程（思考步骤）作为自己的“外部草稿纸”，前一个生成的思考步骤，变成了预测下一个词的上下文。极大解锁了 LLM 的逻辑推理能力

局限

无论 Prompt 多精妙，裸 LLM 依然是一个“缸中之脑”。它不知道今天是几号，不能联网，不能点外卖，知识永远停留在训练截止的那一天。

Agent

核心特征：循环
最有价值的地方：可以调用外部工具

ReAct 架构

ReAct 是一个合成词（Reasoning + Acting）。该架构的核心是将思考和行动交织在一起，形成一个循环：Thought -> Action -> Observation -> Thought -> ...

while not done:
	think()
	act()
	observe()

推理：帮助模型制定、监控和修正行动策略
行动：帮助模型从外部获取信息来锚定推理
两者形成闭环反馈，模型不再是黑箱里自说自话，也不再盲目调用工具——它在有意识地思考、有目的地行动、有依据地调整

大部分 Agent 都采用了“思考-行动-观察”的循环范式。

风险

Agent 的风险也很明显：

循环失控：一直调用工具，不停尝试
错误累积：即使每个步骤 99% 可靠，10 步流程的整体可靠性只有 90%，20 步就掉到 82%（0.99^20）
成本不可控：多轮工具调用导致 token 暴涨
难复现：同一任务多次运行路径不同

Context Engineering

Context 是模型运行时看到的全部信息：

Context = system prompt (系统指令)
		+ user prompt (用户提示)
		+ 短期记忆 (对话历史)
		+ 长期记忆 (跨会话知识)
		+ RAG (检索信息)
		+ Tools (工具定义)
		+ output schema (输出格式规范)

Context Engineering 是构建动态系统，在正确时间、以正确格式，向模型提供正确的信息和工具，让 AI 应用能够完成任务：

Prompt Engineering 关注“这一轮怎么问”
Context Engineering 关注“整个运行时该给模型看什么、不该给模型看什么、什么时候给、以什么粒度给”

为什么需要上下文管理

当 AI 应用从一次性问答进化到多轮对话后，上下文腐烂（Context Rot）问题随之而来：

错误信息进入上下文后被反复引用
信息过多导致注意力分散
不相关内容干扰推理
矛盾信息导致混乱

多轮对话中的上下文管理

大模型本身是无状态的，每一次发新消息，都需要将之前的聊天记录全部打包，重新发给大模型。随着聊天变长，Token 会爆炸，API 成本剧增：

滑动窗口：只保留最近 5 轮对话，扔掉更早的
检索式记忆：把历史对话切片存储，需要时按相关性召回
滚动总结：当对话超过一定长度，让大模型把之前的对话总结成摘要，作为新上下文

Agent 循环中的上下文管理

在 Agent 的循环过程中，上下文极其容易“爆炸”/“被污染”：

工具爆炸输出：“网页搜索”工具返回一个 50 万字符的 HTML 代码，不能直接塞进上下文
长程记忆管理：Agent 要执行一个长达几小时的复杂任务，它需要区分短期记忆（正在做哪一步）和长期记忆（过去总结的经验）
去除冗余的中间轨迹：循环 N 轮次后，优秀的上下文管理需要动态把之前“已尝试但无效的方案”剔除，只保留有用的主干

Workflow

理想与现实碰撞：纯 Agent 走不通

纯 Agent 在实际工程中走不通：

概率累积误差：若 LLM 每步决策准确率 90%，连续 10 步复杂决策后，成功率降到 34%（0.9^10）
工具选择的“维度灾难”：若给 LLM 提供 50 个工具，它在每次循环中，都要阅读 50 个工具的介绍，并在海量选项中做选择，极易选错工具，或进入死循环

在复杂/批量任务场景中，完全的自主 = 完全的不可控，不能把核心业务交给一个“聪明但随时可能发散思维”的黑盒。

Agentic Workflow

传统 Workflow 像一条死板的流水线，规则是确定性的：如果A, 则走路径B; 否则走路径C，传统工具例如 Airflow、n8n 等。

Agentic Workflow 则是将 Agent 与 Workflow 进行结合，常见如下三种模式：

1. 宏观 Workflow 控制，微观 Agent 自主

在宏观的业务流程上，用 Workflow（SOP 图纸）定死；在某个具体的节点上，用 Agent 去发挥自主性。

Workflow 规定：任务必须遵循信息收集 → 数据计算 → 报告撰写这个流水线
Agent 执行：在信息收集这个节点里，放一个“搜集 Agent”。这个 Agent 只被赋予了 3 个工具（Google 搜索、维基百科、知乎搜索）
融合点：在这个节点内，Agent 依然是自主选择工具的（它可以自己决定先搜 Google 还是先搜知乎，搜几次停止），但它绝不可能突然去调用“计算器”或“发邮件”工具，因为它没有这个权限

2. 给 Agent 配备 SOP（SKILL）

纯 Agent 像一个个人能力极强但没有经验的实习生，遇到问题全靠自己 ReAct。我们可以把 Workflow 作为说明书写进 Prompt 中，交给 Agent：

做法：告诉 Agent：当你要退货时，请严格按照以下步骤调用工具：1. 查订单 → 2. 查退货政策 → 3. 调用退款接口
融合点：Agent 依然掌控全局，但它的“思考（Thought）”过程被 Workflow 的规则强约束了

3. Workflow 作为多 Agent 的管理者

在 Workflow 节点上，不再是单纯的代码，而是不同的 Agent
例如一个软件开发 Workflow：
- 产品经理 Agent（负责写需求）
- 程序员 Agent（负责写代码）
- 测试 Agent（负责调用运行工具测试）

姜姜姜的blog

探索

1. 序