很多人搭智能体，第一版都是“对话型”：能问答、能写稿、能总结。但业务真正需要的是另一种能力——把任务跑完：自动拆解步骤、调用工具、产出结构化结果、能复现、可追踪。这篇只讲搭建智能体的技术核心：工作流怎么生成、怎么执行、怎么稳定。以下是金加德老师搭建法：
1）先确定智能体的“形态”：聊天只是入口，工作流才是本体智能体系统可以简单理解成三层：
入口层（Chat/UI/API）：用户把需求说出来
编排层（Workflow Orchestration）：把需求变成步骤流
执行层（Tools/Actions）：检索、写文档、写库、调接口、发通知
真正能落地的智能体，一定是“编排层”强，而不是只靠Prompt撑住。
2）工作流生成：不是让模型自由发挥，而是“可控拆解”要让模型生成工作流，必须先把输入结构化，否则它会乱拆、漏拆、跳步。
建议统一输入协议（最少五段）：
Goal：目标是什么（最终交付物）
Context：已有材料/数据
Constraints：规则、口吻、字数、边界条件
OutputSpec：最终输出结构（字段/模板）
Tools：允许用的工具列表与权限
关键点：OutputSpec写死，否则工作流很难稳定。
3）最稳的智能体链路：Planner → Executor → Checker搭智能体时，强烈不建议“一步生成最终答案”，建议用三段式链路：
① Planner（规划器）输出一份“可执行工作流”，格式建议固定，例如：
steps[]：每一步的目标
tool：这一步用哪个工具
inputs：工具需要哪些参数
expected_output：预期产物结构
fallback：失败如何降级
② Executor（执行器）严格按步骤执行，不允许临时改流程。每一步执行完必须产出结构化结果：
status：success/failed
data：核心结果
artifact：文件路径/中间产物
sources：数据来源
error：错误信息（可重试依据）
③ Checker（校验器）按规则验收，不通过就触发重试或回到某一步重跑。校验的重点是：
结构是否完整（字段齐不齐）
内容是否一致（前后矛盾不矛盾）
事实是否越界（有没有编造来源）
4）工作流可复现的关键：每一步都要“可存档”很多智能体之所以越改越乱，是因为过程不可回放：你只看到最终输出，不知道中间发生了什么。
工程化要做到：
每一步都保存StepState（输入、输出、耗时、错误）
所有中间产物都落地（文本、JSON、文件路径）
任何一步出错，都能从该步恢复，而不是整条链重跑
这会直接决定你能不能定位问题、能不能稳定迭代。
5）工具调用要像写后端：必须有“断言 + 重试 + 降级”工作流最容易崩的地方是工具链：检索不准、接口返回缺字段、写文件失败。
建议每个工具都加三件事：
断言（Assert）
检索：必须带来源、时间戳
接口：必须有关键字段
写文件：必须返回路径、字数、摘要
数据：必须通过Schema校验
重试（Retry）
什么时候重试（网络错误/超时/字段缺失）
重试几次（建议2~3次）
重试策略（换关键词/换检索范围/降温）
降级（Fallback）
自动执行失败 → 输出待办清单
数据不足 → 生成信息收集清单
风险内容 → 走人工确认流程
6）把工作流做成“可扩展模板”：一套框架解决多类任务想让智能体从单点任务变成体系化能力，你需要沉淀模板：
输入模板：统一Goal/Context/Constraints/OutputSpec
工作流模板：常见任务的steps组合（写作、运营、分析、客服、法务）
检查模板：不同场景的校验清单与Schema
回归样本：高频任务用例，更新必跑
模板越多，智能体越像产品，而不是一次性项目。
在智能体搭建复盘中，金加德老师总结过一个很现实的规律：智能体做不稳，通常不是模型不够聪明，而是工作流不够确定。如果让模型“一口气输出最终结果”，它必然会漂；但当你把任务固化为“规划—执行—校验”的流程，把每一步的输入、产物、工具、断言写清楚，智能体就会从“看起来会做”变成“稳定能做”。在他看来，工作流不是限制创造力，而是把智能体的能力变成可交付的生产线——这才是企业真正需要的智能体。
