来源:12-Factor Agents / Factor 1(Natural Language to Tool Calls)
一句话先懂
把“人话需求”翻译成“结构化动作”,让模型负责理解,让代码负责执行。
奶奶版先理解
你跟家里人说:
- “帮我交电费 500”
这句话要真正落地,必须变成明确单据:
- 任务:交电费
- 金额:500
- 账户:国家电网 xx 户号
- 截止时间:今晚 20:00
来源:12-Factor Agents / Factor 1(Natural Language to Tool Calls)
把“人话需求”翻译成“结构化动作”,让模型负责理解,让代码负责执行。
你跟家里人说:
这句话要真正落地,必须变成明确单据:
来源:12-Factor Agents / Factor 2(Own your prompts)
提示词是你的核心业务逻辑之一,不要完全交给黑盒框架。
你请了一个能力很强的帮手,但你只说“你看着办”。
如果你给的是明确说明书(步骤、边界、禁区、异常处理),稳定性就会高很多。
Factor 2 的意思不是“框架不能用”,而是:
来源:12-Factor Agents / Factor 3(Own your context window)
模型是“无状态函数”,它只会基于你给的上下文做判断。上下文质量,直接决定输出质量。
看病时如果只说“我不舒服”,医生只能猜。
如果你给出病历、检查单、过敏史,诊断就会更准。
上下文窗口就是给模型的“病历袋”。
来源:12-Factor Agents / Factor 4(Tools are just structured outputs)
工具调用不是魔法,本质是模型输出结构化数据,然后由确定性代码执行。
你在餐厅点菜时,给服务员的是“菜名+份数”的单子,不是自己进后厨炒。
“点菜单”是结构化输出,“后厨流程”是确定性执行。
来源:12-Factor Agents / Factor 5(Unify execution state and business state)
尽量用一条事件线程同时承载“业务发生了什么”和“流程走到哪”,减少双状态系统的复杂度。
做饭时你记一本流水账:
这本账既告诉你“饭做到哪步”,也告诉你“发生了什么事”。
不需要再单独维护一本“流程状态账”。
来源:12-Factor Agents / Factor 6(Launch/Pause/Resume with simple APIs)
智能体要像标准任务系统一样可管理:启动、查询、暂停、恢复都要有清晰 API。
炖汤不是必须一直守着火。你可以:
智能体也应支持这样“可中断、可续跑”的节奏。
来源:12-Factor Agents / Factor 7(Contact humans with tool calls)
“请求人工介入”也要做成结构化工具调用,而不是模型随口说一句。
社区办事时,工作人员给你的不是“你看着办”,而是标准表单:
这就是结构化协作。
LLM 在“输出自然语言”还是“输出 JSON”之间,经常是一开始就做高风险选择。
一种可实验策略是:让模型尽量总是输出结构化对象,用 intent 区分不同动作。
来源:12-Factor Agents / Factor 8(Own your control flow)
控制流(循环、分支、暂停、重试、升级)必须由确定性代码掌控,不能交给模型随意决定。
导航会建议“右转”,但方向盘和刹车必须在你手里。
遇到施工、堵车、危险路段,你得自己决定绕路还是停车。
来源:12-Factor Agents / Factor 9(Compact Errors into Context Window)
把错误转成结构化、可行动的信息回灌给模型,促成自愈;同时严格限制重试,避免无限打转。
做菜失败了,不是直接放弃,而是记住“这次盐放多了”,下一次修正。
但连错三次就要请会做的人帮忙,而不是死磕。
来源:12-Factor Agents / Factor 10(Small, Focused Agents)
不要追求一个“全能大脑”,要建设一组“专科智能体”,每个只解决一个清晰问题。
看病时你不会找一个医生同时看牙、做眼科手术、做心脏手术。
专科分工更靠谱。
任务越大、步骤越多、上下文越长,模型越容易迷失。
把任务边界收窄,通常能显著提高成功率和稳定性。