Python后端工程师：做了五年Flask，我转型做了大模型Agent应用开发

程序学到昏

206人浏览 · 2026-07-17 17:56:59

程序学到昏 · 2026-07-17 17:56:59 发布

一、一个让我冒汗的PRD

我盯着产品经理发来的PRD，手指在键盘上悬了半天，硬是没敲下去。

那页纸上写着：“用户输入一句话，系统自动调用查询订单、检查库存、生成物流建议三个工具，最后输出一份可执行的补货方案。”

我干了五年Python后端，Flask、FastAPI、SQLAlchemy闭着眼都能写。但那个PRD里没有HTTP接口、没有数据库表、没有状态码——只有一个"Agent"，说要"自己决定调用什么工具"。

我脑子里第一个念头是：这玩意儿怎么测试？

二、传统后端在大模型时代的尴尬

先别说我菜，这五年我不是白干的。RESTful API设计、微服务拆分、数据库事务、缓存一致性——这些我都有底气。但大模型应用出现后，我发现后端的工作边界变了。

以前的需求是确定的：前端要什么，我就给什么接口。现在的需求是模糊的：用户说一句话，系统要自己理解、自己规划、自己调用工具、自己判断结果够不够。我不只是写接口，我要写一个"能思考的流程"。

更扎心的是，组里新来的实习生用LangChain三天搭了个Demo，能查天气、能算汇率、能写邮件。老板在群里发：“这个方向很有价值，后端组要跟上。”

我跟mentor说：“这东西可靠性怎么保证？”

他说：“你先做出来，再考虑保证。”

三、我开始真正理解Agent

我花了两个周末，把LangChain、LangGraph、OpenAI Function Calling的文档和源码都翻了一遍。才明白一件事：

Agent不是替代后端，而是把后端的业务能力以自然语言接口暴露出去。

用户说的话是输入，大模型负责理解意图和规划步骤，后端的工具（函数/API）负责执行具体动作。Agent是中间层，把"人的语言"翻译成"机器的调用链"。

我把公司的几个核心接口包装成了工具：

@tool
def query_order_status(order_id: str) -> str:
    """查询订单状态，返回订单当前物流和交付时间"""
    ...

@tool
def check_inventory(sku: str) -> int:
    """查询指定SKU的库存数量"""
    ...

@tool
def recommend_replenishment(sku: str, days: int) -> str:
    """基于历史销量生成补货建议"""
    ...

然后用LangChain的AgentExecutor把它们串起来。第一次运行时，它真的自己调用了三个工具，生成了一份补货方案。虽然格式乱七八糟，但逻辑是对的。

四、我做了三个具体改造

第一件事：把工具接口设计从"面向前端"变成"面向模型"。

以前写接口，我考虑的是前端怎么调用、参数怎么校验。现在写工具，我要考虑的是：大模型看到这个函数名和docstring，能不能理解它该什么时候调用？

我开始给每个工具写极其详细的docstring，函数名不用缩写，参数说明带示例，返回值结构化。比如：

@tool
def query_order_status(order_id: str) -> str:
    """
    查询指定订单的当前状态和预计送达时间。
    参数：
        order_id: 订单编号，例如 "ORD-2025-001"
    返回：JSON字符串，包含status和estimated_delivery字段
    """

这一步让Agent调用准确率从55%提升到82%。

第二件事：把思考过程可视化，让Agent不再黑盒。

大模型做决策时，我们看不到它怎么想的。产品上线后，用户反馈"AI乱回答"，我根本不知道错在哪。

我加了一层Trace记录：每次Agent执行，记录中间步骤、工具调用、模型输出。用LangSmith做追踪，把每个会话的调用链存下来。出问题的时候，我能回放整个过程，定位是哪一步规划错了。

第三件事：加护栏和兜底，让Agent敢上线。

Agent最大的问题是不可控。我设计了三层护栏：