把一个智能体接进真实业务，难点通常不在模型本身，而在流程边界。我们先把业务拆成可以描述的节点，再决定哪些节点交给模型判断，哪些节点必须保留人工确认与可回滚的记录。
先写清楚流程，再选工具
需求梳理阶段要回答三个问题：输入从哪里来、输出交给谁、出错时怎么办。这三个问题没定下来，后面无论换哪个模型、加多少工具，都只是在把不确定性往后推。
把知识、工具与流程分开组织
我们倾向于把知识资料、外部工具调用和流程编排做成三个独立层。这样一来，业务规则变化时只需要调整流程配置，知识库更新时不用重写提示词，工具升级也不会牵动整条链路。
上线之后要看得到
交付不是终点。运行记录、异常分支与人工接管次数，决定了后续能不能持续调整。我们会在交付文档里保留这些观测口径，方便后台维护时按同一把尺子复核。
小结
- 流程边界先于模型选型
- 模块化组织便于持续迭代
- 运行观测与交付文档同样属于交付物
这套做法不追求一次做完所有功能，而是让系统在业务变化时可维护、可解释、可继续演进。