FDE Training · Module 05

05

Agent 编排与提示工程

模块 05 · Agent 编排与提示工程

本章目标：让模型从"回答问题"升级为"会动手干活"——自己定计划、调工具、跑流程、失败了会重来。同时把 Prompt 从"demo 会跑"做到"生产级稳定"。Agent 编排是 2026 FDE 的重点新增要求。

5.1 什么是 Agent（大白话 + 和图对比）

光有模型：你问一句，它答一句。
有 RAG：它能查知识库再答。
有 Agent：它能"自己决定做什么"——比如你说"把上季度营收整理成报告发群里"，它会自己：查数据库 → 画图表 → 写报告 → 去调用发消息工具 → 成功了告诉你。

Agent = 大模型(思考) + 工具(能调用的API/函数) + 编排(计划/记忆/循环)

FDE 场景里 Agent 常用来做多步骤业务流：

智能客服：识别意图 → 查订单 → 查物流 → 需要时转人工。
合同审批：审单 → 发现问题 → 查条款 → 起草建议 → 发给业务复核。
数据报表：取数 → 清洗 → 生成图表 → 按模板输出。

5.2 Agent 的三大件：工具调用 (Function Calling) 是地基

没有工具调用，Agent 就只是"会聊天"。Function Calling 让模型能表达"我要调这个函数、参数是这个"，你的代码再真正执行。

OpenAI 兼容的调用示意：

from openai import OpenAI
client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "query_order",
        "description": "按订单号查询订单状态",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string", "description": "订单号"}
            },
            "required": ["order_id"]
        }
    }
}]

msg = {"role": "user", "content": "帮我查一下订单 A123 到哪了"}
r = client.chat.completions.create(model="gpt-4o",
    messages=[msg], tools=tools, tool_choice="auto")

# 模型可能返回: 需要调用 query_order(order_id="A123")
if r.choices[0].message.tool_calls:
    call = r.choices[0].message.tool_calls[0]
    # 你来真正执行, 把结果回喂给模型
    result = real_query_order(call.function.arguments)
    # ... 把 tool result 作为新 message 继续追问

关键坑（面试常考）：

工具描述要好：模型靠 description 决定要不要调、调哪个，写清楚比代码优雅更重要。
参数解析要稳：模型可能返回 JSON 略有瑕疵，要能容错解析。
循环上限：模型可能反复调工具不放，要给"最大轮数"。
失败处理：工具报错要回喂给模型让它调整，而不是直接崩。

补一段：ReAct 循环——Agent 的心跳，通俗拆解

Function Calling 单次调用只是"模型喊一嗓子、你执行一下"。真正让 Agent 能连续干活的，是 ReAct 循环：Reason（想）+ Act（做）+ Observe（看），然后转圈。拆开就四步：

Thought（想）：模型先自己琢磨"我该干嘛、还缺什么信息"。
Action（做）：决定调哪个工具、带什么参数，交给你执行。
Observation（看）：你把工具返回结果回喂给模型。
回到第 1 步继续想，直到它判断"任务完成了"再输出最终答案。

一句话：想 → 做 → 看 → 再想，转到任务完成为止。这就是 LangGraph 那套状态机在单场景下的最小循环；多 Agent 协作（5.3.3）其实就是把这套循环拆给多个角色各转各的，再用共享记忆/状态串起来。完整的 ReAct 代码、Agent 架构五要素（规划/记忆/工具/执行/反馈）与多 Agent 协作的坑（死锁、token 成本爆炸），去 Rust + AI 全栈页一口气补完。

5.3 流行编排框架：LangGraph（重点）/ CrewAI / AutoGen

5.3.1 为什么要用框架

手写"模型循环 + 工具调用"会越写越乱。框架帮你管状态、记忆、控制流、多 Agent 协作，还能可视化、可观测。

LangGraph：图结构，节点 = "干活"，边 = "下一步去哪"，支持条件分支、循环、状态持久化。适合明确的多步业务流，FDE 首选。
CrewAI：把多个角色（Agent）组成一个"团队"（Crew）协作，写起来更口语化，适合角色分工场景。
AutoGen：多 Agent 对话协作，偏研究原型。

5.3.2 一个 LangGraph 最小流程（理解状态机）

from typing import TypedDict, Literal
from langgraph.graph import StateGraph

class State(TypedDict):
    query: str
    intent: str
    answer: str

def route(state: State) -> Literal["query_order", "chat"]:
    return "query_order" if "订单" in state["query"] else "chat"

def node_order(state):
    return {"answer": f"订单 {state['query']} 正在运输中"}
def node_chat(state):
    return {"answer": "您好，我是客服助手。"}

g = StateGraph(State)
g.add_node("query_order", node_order)
g.add_node("chat", node_chat)
g.add_conditional_edges("__start__", route, {"query_order": "query_order", "chat": "chat"})
g.set_finish_point("query_order"); g.set_finish_point("chat")
app = g.compile()

要理解的本质（面试考点）：Agent 编排 = 一个可控的状态机：每一步想清楚"做什么 → 决定下一步 → 在哪结束"，而不是让模型自由发挥到失控。

5.3.3 多 Agent 协作

为什么要多 Agent：一个 Agent 又理解需求、又查数、又写报告，容易糊成一团。拆成"需求理解 Agent → 取数 Agent → 报告 Agent"，各干各的，还便于单独评测。
协作方式：握手——前一个 Agent 输出（结构化）作为后一个的输入；共享一个 Memory / 状态。

5.4 Agent 可观测性：追踪工具调用链路、失败分支、错误恢复

客户最担心的就是"黑盒"——AI 到底干了啥、为啥这么干、挂在哪。所以 Agent 必须可追踪、可解释：

记录每一个步骤：做什么工具调用、参数是什么、返回什么、用了多少 token、耗时多少。
完成一个 request_id 贯串全链：一次用户任务 → 若干步骤日志，能回放。
记录失败分支：哪一步失败了、重试了几次、最后怎么兜底。
错误恢复：失败 → 自动重试 / 降低难度重试 / 转人工 / 给用户明确提示。

steps = []   # 或写进结构化日志/DB

def log_step(name, params, result, cost, ok):
    steps.append({
        "req_id": req_id, "name": name,
        "params": params, "result_head": str(result)[:200],
        "tokens": cost, "ok": ok, "ts": time.time(),
    })

可观测 > 模型智商：客户环境里，"能解释"往往比"答得漂亮"更重要。

5.5 Prompt 工程：从 Demo 到生产级稳定

5.5.1 一个生产级 System Prompt 长什么样

你是XX银行合同审单助手。

【职责】根据给定资料审查合同关键风险点，输出结构化审单结论。

【输入】会提供: 合同片段 + 用户问题。
【约束】
- 仅依据提供资料回答；资料无法判断的标注[待人工核实]，不得臆测。
- 输出必须为 JSON，字段: verdict(approve/reject/need_manual), reasons(list).
- 语言使用简体中文。

【输出示例】
{"verdict":"approve","reasons":["条款合规","无重大风险"]}

【多轮说明】若用户追问，基于上一轮结论补充，不重复整段结论。

5.5.2 Demo Prompt vs 生产 Prompt（面试高频对比）

维度	Demo	生产级
输出	随便回答	结构化 JSON + 严格格式
约束	无	边界明确、不接受越权指令
处理幻觉	不管	资料没有就直说/待人工核实
稳定性	调一次就行	一套评估集反复回归（模块 06）
安全	不管	Guardrails、防注入（模块 07）

5.5.3 三个常用技巧

Few-shot（给范例）：给一两个输入输出示例，尤其对格式复杂场景。
思维链（Chain-of-thought）：复杂任务让模型"一步一步想、再给结论"，准确率更高（注意：生产可能要隐藏中间推理）。
系统提示词 vs 用户提示词分离：规则放 system，动态内容（资料、用户问）放 user，清晰且安全。

5.6 模块练习

给一个模型实现"工具调用"：做一个 query_order 函数，模型识别意图并调用，处理一次工具调用+失败重试的完整闭环。
用 LangGraph 搭一个"取数→生成报告"两节点流程，加一个条件分支（用户要报表就生成图，否则聊两句）。
给 Agent 加"可观测性"：把每一步工具调用、token、耗时、成功与否打进结构化日志。
写一个生产级 System Prompt（审单），加入"资料没有就待人工核实"和 JSON 输出约束。
造 3 个"Agent 可能反复循环/越权"的场景，设计兜底（轮数上限、权限白名单、转人工），并测试。

5.7 本章面试题

"Function Calling 是什么？Agent 为什么依赖它？" → 答：让模型能表达"要调用某个函数、参数是什么"的机制，你的代码真正执行并回喂结果。没有它 Agent 只会聊天不会实操，无法闭环业务动作。
"多 Agent 你什么时候用，什么时候不用？" → 答：任务能被清晰拆成不同职责且需要隔离/单测时用（如取数、报告、审核分段）；简单任务单 Agent 即可，多 Agent 会引入状态混乱和成本。
"你怎么保证 Agent 不失控（无限循环/乱调工具）？" → 答：最大轮数上限、工具白名单 + 参数校验、超时兜底、记录失败分支、异常降级或转人工；并用可观测性日志追踪每一步。
"生产级 Prompt 和 Demo 的本质区别？" → 答：确定性。生产要结构化输出、边界约束、幻觉兜底、安全护栏、并有一套评估集做回归，而不是"这次能跑通"。
"Agent 出错了你先怎么排查？" → 答：看追踪日志：先看意图识别对不对 → 工具调用参数是否合理 → 工具返回是否符合预期 → 模型对工具结果的理解 → 哪一步失败/反复。分阶段定位，而不是重跑一遍。

5.8 小结

Agent = 大模型 + 工具 + 编排（状态机），让它"自己干活"。
工具调用是地基：工具描述要比代码更仔细、参数解析稳、设轮数上限。
LangGraph 是有序多步流程首选，本质是可控状态机。
可观测性 > 模型智商：追踪每一步、记失败分支、可回放。
Prompt 工程目标是"确定性"：结构化输出、边界约束、幻觉兜底。
下一章：怎么证明"这套东西可靠"——评估体系 Evals。