把生成结果变成可检查的任务
一次客服请求可能同时包含三个不同任务：“解释退货政策”“找到订单”“执行退款”。解释是生成任务，找订单是授权查询，退款是账本变更。若把三者都交给一个返回字符串的函数，界面无法判断退款是否真的发生，也无法在超时时判断该不该重试。
本节前置是 Python 的函数、字典、异常与 JSON，见Python 路线。所有完整实验只用标准库，保存为独立 .py 文件，以 python3 文件名.py 执行。这里注入固定模型响应，验证应用边界；真实模型接入在通用 API。固定响应不能证明模型质量。
先定义可观察结果
为“把工单分到技术或账单队列”定义输入文本、允许类别、拒绝条件与后续效果。模型可以提议类别，应用只接受两个枚举值。一个合法 JSON 可能是数字、数组，甚至带有未知字段，所以解析成功只是第一道门。
import json
def classify(text, generate):
if not isinstance(text, str) or not text.strip():
raise ValueError('empty input')
raw = generate(text)
value = json.loads(raw)
if not isinstance(value, dict) or set(value) != {'queue'}:
raise ValueError('invalid shape')
if value['queue'] not in ('billing', 'technical'):
raise ValueError('invalid queue')
return {'status': 'classified', 'queue': value['queue']}
calls = []
def fixture(text):
calls.append(text)
return '{"queue":"billing"}'
assert classify('发票抬头错误', fixture)['queue'] == 'billing'
try:
classify(' ', fixture)
except ValueError as error:
assert str(error) == 'empty input'
else:
raise AssertionError('empty input accepted')
assert calls == ['发票抬头错误']
try:
classify('退款', lambda _: '{"queue":"billing","refund":true}')
except ValueError as error:
assert str(error) == 'invalid shape'
else:
raise AssertionError('extra instruction accepted')
print('contract ok')结果是 contract ok。第二个输入在调用模型之前失败，第三个输入在模型返回之后失败；前者节省调用，后者限制输出可进入的业务分支。即使模型输出 refund: true，应用也没有把它解释成退款授权。这个因果顺序比“提示词要求模型遵守规则”更可靠。
六层各自保存什么
交互层收集文本和展示任务状态；应用层验证身份及任务合同；模型适配层转换供应商响应为内部结果；知识层返回有版本的证据；工具层执行授权业务操作；基础设施层提供事务、队列和观测。它们是责任边界，不要求从第一天就部署成六个服务。单进程中的独立函数同样可以建立这些边界。
沿一个请求追踪：应用层绑定服务端确认的 tenant → 知识层按该租户检索 → 适配层发送最少必要证据 → 应用层验证分类 → 工具层以已授权身份处理工单。模型不知道的租户不能由它猜出来；模型给出的租户也不能覆盖认证上下文。
什么时候需要工作流或 Agent
已知“分类后分派”是固定两步，用代码控制顺序即可。如果研究问题需要根据证据决定下一次查询，才把下一步选择交给模型，同时约束工具、预算与停止。多 Agent 有价值的前提是权限、上下文或独立验证责任确实不同。为同一工具和同一材料复制三个角色会增加调用次数，却不自动产生独立证据。
高风险任务把“生成建议”和“提交变更”分开。任务完成必须落在可检查的业务状态上：拿到分派 ID 才算分派成功；模型说“已处理”不能作为凭证。
练习
在原函数中增加 abstain 类别，返回 status: needs_review，其余合法类别仍为 classified。分别检查数字 JSON、未知类别和合法弃答，非法情况不得返回成功。不要在模型失败时默认分到 billing。