“帮我看一下，SO-1024 这批货做到哪一步了？明天还能发吗？”
假设这是生产主管发给厂内助手的一句话。前半句要查生产记录。后半句还得看有没有待检、缺料或者尚未确认的发运安排。两句话看起来连在一起，需要的数据却不一样。
把问题直接发给大模型，它能读懂你在问进度和发货风险。要回答“这单在终检”，系统得拿到这张订单的生产记录。要确认明天能不能发，还得知道出货条件有没有满足。这个例子全程使用模拟数据。
这套教程面向会写代码的读者。今天先跑一个最小的查单流程，分清模型和业务程序各负责什么。准备 Python 3.10 和 uv 就够了。
大模型会读问题，订单状态由业务系统提供
大语言模型收到一段文字，会根据这次提供的信息生成输出。输入可以包含用户的问题、应用给它的指令，以及程序查回来的订单记录。指令里可以写“查不到就问订单号”，查到的记录里则可能写着“当前工序为终检”。
模型读写的信息会被拆成小单位，叫 Token。一次请求能处理的 Token 有上限，这就是上下文窗口。你把几十份工艺文件、聊天历史和订单明细一起塞进去，都会占这个空间。查一张单时，可以先筛出订单号、当前工序和数据更新时间，再把这些字段交给模型。
后面会用到模型的两种能力。结构化输出是让模型按规定字段返回结果，比如把问题拆成 intent=order_progress 和 order_id=SO-1024。工具调用是让模型提出一个动作，比如请求调用 get_order_progress，并把订单号作为参数。程序拿到字段后，还要验证订单是否存在、当前账号是否有权查看。字段长得对，和订单号填得对，并不是一回事。 模型能力说明 · 结构化输出文档 · 工具调用文档
固定工作流和 Agent 会怎么查这张订单
如果界面上有一个“查询生产进度”入口，用户已经选好了订单，代码就可以提前写定步骤。校验权限，查询生产记录，整理结果，返回给用户。缺订单号就请用户补齐。这样的固定工作流也可以用模型润色回答，查询步骤仍由程序决定。
如果是一个自由输入的助手，用户可能一边问生产进度，一边问能否发货。可以让模型从已授权的工具中选择先查工序。看到结果显示等待质检后，模型可以再请求查质检状态；如果只有工序数据可用，就先说明哪些信息已确认、哪些还缺。程序负责执行调用，并把结果交回模型。模型根据结果决定是否继续，这就是一种常见的 Agent 执行方式。 工作流与 Agent
权限核验、报表统计和写入前的审批可以直接做成程序节点。等我们用 LangGraph 把这些步骤接起来时，会把允许模型决定的地方单独标出来。
动手跑一次查单
在空目录运行下面的命令，然后把 Python 代码保存为 order_demo.py。代码先用字典代表订单系统，后面会把同一个查询入口换成 PostgreSQL。
# 用 uv 为本次练习创建 Python 3.10 项目
uv init --bare --python 3.10
# 模拟订单记录。后续会把字典查询换成只读数据库查询。
ORDERS = {"SO-1024": {"stage": "final_inspection", "status": "in_progress"}}
def get_order_progress(order_id: str | None) -> dict[str, str]:
"""读取 order_id 对应的模拟工序，返回处理状态及查到的字段。"""
# 缺少编号时先补问，查询留到用户给出完整参数以后。
if not order_id:
return {"result": "need_order_id"}
# 从业务数据取状态。查不到时返回一个独立的处理结果。
record = ORDERS.get(order_id)
if record is None:
return {"result": "not_found"}
# 将这次回答需要的业务字段交还给上层。
return {"result": "found", "order_id": order_id, **record}
# 三次调用分别覆盖正常查询、缺少订单号和查无记录。
for order_id in ("SO-1024", None, "SO-9999"):
print(get_order_progress(order_id))
# uv 会在首次运行时准备项目环境并执行示例
uv run --python 3.10 python order_demo.py
终端会打印三行。第一行的 result 是 found，工序是 final_inspection，也就是终检，状态为处理中。第二行是 need_order_id，第三行是 not_found。
可以把第一条订单的 stage 改成 packing，再跑一遍。第一行会跟着变成包装，另外两条仍分别表示需要订单号和查无记录。到这里，我们已经有了一个输入输出清楚的查单函数。将来换模型时，可以继续用这三个例子检查它能不能提取正确的订单号，能不能根据查单结果说清楚现状。
接下来怎么用同一个项目往下做
下一篇会拿工序查询、工艺文件和经营报表各举一个例子，讲怎么比较模型的中文理解、字段提取、工具选择和读表能力。选模型时，拿自己业务里的问题和预期答案做小样本测试，会比只看一张通用榜单更容易发现问题。
等选型和最小图跑通，我们会给同一个工厂助手加上版本化的工艺规程、内规查询和经营报表。最终用一张可能延迟的订单把几项功能串起来。查到的事实来自业务系统，允许执行的动作由代码控制，确认后才创建异常工单。读者可以先用模拟数据跑完，再把其中一个工具替换成自己项目里的接口。