AI Native Builder

主题

第 4 章｜为什么智能体时代更需要 AI Native Builder ​

周一早上，澄川工业的销售许岚打开 CRM，发现同一客户名下多了两条相同的跟进任务，预计成交日期也被提前了一个月。她没有做过这些修改，系统日志却显示操作身份属于“客户跟进助手”。

前一天的试运行中，助手读取会议记录，判断客户希望尽快采购，于是调用工具更新预计成交日期并创建跟进任务。第一个调用成功，第二个调用超时。助手无法确认任务是否已经创建，便自动重试了一次，留下两条任务。

更麻烦的是，“尽快采购”来自一段措辞含混的对话。客户说的是“预算批准后尽快”，审批时间并不确定。助手把条件性表达变成了确定日期，还在没有销售确认的情况下改变了系统状态。

这次试运行发生在第 3 章那次角色契约会议之后。会议上已经约定：两项低风险字段须销售确认后写入；价格、成交日期和对外任务不得自动提交；未经确认的写入或重复任务应立即暂停。试运行却临时打开了预计成交日期写入和创建跟进任务，也没有把“状态未知不得重试”写进工具。事故不是契约不存在，而是契约还停在会议记录里，没有成为权限、状态检查和停止条件。

这仍是教学案例。它没有证明某种 Agent 产品必然发生事故，只用来揭示一种结构变化：当 AI 能选择工具并执行动作，错误不再停留在屏幕上的一句话里。它会进入业务系统，影响后续人员和流程。

这一章要解释的正是这个变化。我们会区分确定性自动化、LLM 工作流和 Agent，用同一个任务比较三种设计，再学习怎样为每个动作选择自主性。最后，我们会完整走过一次暂停、核对、恢复和修复。

对企业内部的 AI Native Builder 来说，这正是“怎样把 AI 的效果稳定下来”和“怎样推进生产可用”两个问题的交汇点。模型能力只是输入；权限怎么设、状态怎么管、人审放在哪步、失败了怎么恢复、出了事谁担责，这些环节都需要由 Builder 串联起来统一设计。

从输出质量走向环境状态 ​

传统聊天应用主要返回内容。内容有错，用户往往还能在复制、发送或执行前看见。一旦 AI 获得工具，它除了返回内容，还会产生另一类产物：外部环境中的状态变化。

状态可以是一条 CRM 记录、一封已发邮件、一个退款决定、一项代码提交，也可以是权限、库存或账户余额。它们有的容易撤销，有的会触发后续流程，有的甚至无法完整恢复。

OpenAI 的 Agent 构建指南把 Agent 描述为能够代表用户完成任务的系统。模型管理工作流执行，根据当前状态选择工具，并在明确约束内读取信息或采取行动。简单聊天或单次分类器不属于这个定义。

这样一来，评估的范围也跟着变了。除了模型理解是否正确，还要看工具、参数和对象选得对不对；除了单步输出，还要核对环境最终处于什么状态；出了错，系统能否及时停住、把控制权交回人手里，同样要纳入评估。

澄川事故里，摘要质量并非主要矛盾。系统在三处出现问题：把条件性意图解释成确定日期；允许模型直接修改高影响字段；对“超时但可能成功”的工具结果没有状态核对。修一个提示词无法同时解决这三件事。

三种系统完成同一任务 ​

团队常把所有带大模型的自动执行都称作 Agent。这个叫法会掩盖架构差异，也让大家误以为更高自主性代表更先进。

Anthropic 的 Building Effective Agents区分了 workflow 与 agent：前者由预定义代码路径编排模型和工具，后者由模型动态决定过程和工具使用。文章还建议从最简单的方案开始，只在结果确实改善时增加复杂度。

为了看清差异，我们让三种系统处理同一项会后跟进任务：读取会议记录，识别客户需求，准备 CRM 更新，并在适当时候创建下一步任务。

确定性自动化：路径可以预先写死 ​

第一种方案不用模型判断。日历提供参会人，CRM 客户编号来自会议邀请，下一次联系日期由销售在表单中选择。程序校验必填字段后更新记录，并把成功或失败返回给用户。

它适合边界清晰、输入结构化、规则容易维护的步骤。模型没有加入，并不表示方案落后。确定性路径更容易测试、解释和恢复，也不会凭空解释客户意图。

局限也很明确：它不能从自由对话中判断客户关心哪项产品限制，遇到未预先定义的表达时只能让人填写。若主要负担正是阅读长记录，单纯表单无法解决全部问题。

LLM 工作流：路径固定，局部需要语言判断 ​

第二种方案仍由代码控制顺序：先取得会议记录，再检索当前产品资料，调用模型提取客户原话和建议字段，通过规则校验后生成预览。销售确认，程序才提交 CRM 更新。

模型负责处理非结构化内容，却不决定是否跳过人审，也不自行增加工具。失败分支由代码明确处理。比如依据为空就停止生成建议，接口超时就查询状态，不让模型自由猜测下一步。

澄川目前的大部分任务适合这种形态。工作路径已知，真正不确定的是语言理解和资料匹配。把模型放在局部判断点，可以获得能力，同时保留可预测的执行路径。

Agent：路径难以提前完整描述 ​

第三种方案给模型一个目标和一组工具。它可以根据会议内容决定先查哪个产品、是否补充客户历史、需要几轮检索、是否请求销售提供更多信息，并根据环境返回继续或停止。

这种形态适合步骤数量和顺序难以预先确定、需要在执行中持续判断的任务。OpenAI 的指南把复杂判断、难维护规则和大量非结构化数据列为更可能适合 Agent 的条件；Anthropic 也把难以硬编码固定路径的开放问题作为使用场景。

灵活性带来新成本。每多一次自主选择，团队就多一个要评估的分支；每多一个可写工具，就多一种状态错误；循环越长，延迟、费用和错误累积越明显。因此，Agent 需要的建设纪律通常比固定工作流更多。

三种形态可以压缩为下面的比较：

系统形态谁决定执行路径适合的任务主要代价
确定性自动化代码与规则稳定、结构化、边界清楚难处理开放语言与大量例外
LLM 工作流代码定步骤，模型做局部判断路径稳定、输入非结构化要评估局部不确定性与模型变化
Agent模型在约束内动态规划和选工具路径难预定义、需持续环境反馈分支、状态、成本和恢复更复杂

选择顺序应该从任务出发。先问固定规则能否满足，再问局部模型判断是否足够，最后才判断是否需要模型控制流程。系统名称不会替你承担增加的复杂度。

自主性应该按动作选择 ​

即使一个项目确实使用 Agent，也不必让所有动作共享同一级别。读取公开资料、准备内部草稿、修改客户记录和发送外部承诺的错误代价完全不同。

讨论自主性时，不要给整个系统贴一个笼统等级。团队应逐项说明 AI 能对某个动作做到什么程度，以及人怎样检查、批准或接管。

动作方式含义人的责任澄川示例
AI 只建议提供分析或建议，不准备正式动作人自行决定并执行建议下一步
AI 准备结果准备草稿、参数或变更预览人检查后，由确定性系统执行准备 CRM 四字段更新预览
人批准后执行可触发有限、可恢复的动作白名单、字段限制、人工批准、审计和停止销售确认后写入四个内部字段
满足条件时执行在已批准条件内连续执行多步持续监控、抽查异常、明确预算澄川当前不采用；若以后允许，也只限特定客户类型的内部备注
在明确边界内自主执行在相对开放但已有边界的范围内规划和行动人主要管理政策和异常澄川当前不采用

这五档与术语表使用同一套名称。让 AI 准备内容、由人确认后执行，不一定比让 AI 连续执行多步动作差。若动作不可逆、涉及对外承诺或错误难以及时发现，让人确认可能是更合适的设计。只有在净收益增加、失败可观察、权限可限制且恢复可行时，才值得增加 AI 的动作权限。

澄川可以让参会人读取保持确定性自动化，让 AI 只对需求识别提出建议，并准备 CRM 更新预览，由销售确认后提交。即使未来允许 AI 在已批准条件内更新个人内部备注，对外邮件仍应由人决定和发送。系统整体没有必要获得一个笼统的“半自动”标签。

Agent 内部可以灵活，外部契约必须稳定 ​

模型可以动态规划，不表示业务目标、数据边界和责任也能跟着即兴变化。Agent 内部选哪条路径都行，但外部必须固定一组契约，让每次选择都有边界、能被检查。

目标契约：怎样才算完成 ​

“跟进客户”太模糊。它可能指记录会议、创建内部任务，也可能被理解为直接发信。目标契约要写明任务终点、排除项和成功证据。

澄川把目标写成：“在销售确认前，准备有依据的 CRM 更新；本阶段不发送外部消息，不修改价格和预计成交日期。”这两句直接限制了 Agent 可以规划的空间。

上下文契约：可以相信哪些材料 ​

Agent 会使用它得到的材料，但无法凭空知道哪份文档仍有效。上下文契约定义允许的来源、版本、时间、数据权限和冲突处理。

如果两份产品资料结论不同，系统不能任意选一份。它应优先有效版本；无法判断时，停下并显示冲突。来源和版本也要进入运行轨迹，供用户和评估人员核对。

工具契约：一次调用到底意味着什么 ​

工具名称和描述只是入口。可靠契约还要说明输入、输出、身份、权限、副作用、超时语义、幂等方式和错误返回。尤其要区分“失败”“未执行”和“结果未知”。

澄川的创建任务接口若返回超时，系统不能假定失败。它要凭请求标识查询实际状态。查不到时再交给人处理，而不是盲目重试。

状态契约：允许发生哪些变化 ​

状态契约列出对象可从什么状态进入什么状态，以及哪些转换必须保留前置条件。它让团队检查最终环境，而不只检查 Agent 是否说“完成”。

例如，预计成交日期只有在销售提供明确日期并确认后才能改变。Agent 推断出的日期最多进入候选字段，不能直接覆盖正式记录。这条规则应由系统执行，而不能依赖模型对提示词的自觉遵守。

人审契约：谁在什么时候介入 ​

“需要人工审核”仍然不够。团队要指定审核人、看到哪些信息、能做什么、多久未处理会怎样。没有依据和差异提示的确认按钮，只会训练用户快速点击。

澄川的预览同时显示会议原句、引用资料、旧值和建议新值。销售可以接受、修改或拒绝，并选择原因。高风险字段不会出现在可提交集合中。

停止与恢复契约：错误发生后怎样接手 ​

停止条件包括连续工具失败、结果状态未知、上下文冲突、超出权限和触发敏感信息规则。恢复契约说明谁暂停、怎样核对环境、哪些动作能撤销、怎样通知受影响的人以及何时恢复运行。

这些契约共同形成运行不变量（invariant），即无论模型如何规划，任何执行路径都必须满足的规则。例如“任何外部消息都必须由销售本人发送”“未知状态不得自动重试非幂等写入”。不变量不随模型临时计划改变，每条运行轨迹都应接受检查。

一次事故怎样被真正处理 ​

回到开场的两条重复任务。团队先撤销助手的 CRM 写入令牌，保留读取权限，并暂停所有未完成运行。这个动作阻止错误继续扩散，同时保留调查所需信息。

接着，Builder 和 IT 用运行编号核对工具调用与 CRM 审计日志。他们确认日期更新已经成功，第一次创建任务也已成功，只是接口响应在返回途中超时。第二次创建产生了重复对象。

销售负责人判断日期修改缺少业务依据，批准恢复原值；重复任务中，保留第一条并关闭第二条。由于没有外部邮件发出，影响仍停留在内部系统。如果动作已经触达客户，恢复步骤还必须包含通知和业务纠正。

修复不止是删除两条错误记录。工程团队为创建任务增加幂等键和结果查询，把“状态未知”设为人工接手条件；产品团队把预计成交日期移出自动写入工具；评估集加入条件性时间表达和超时后已成功的样本。

最后，团队记录事故经过、影响范围、处置决定和重新开放条件。只有新版本在沙盒通过回归，权限负责人重新批准，销售试用者确认预览信息足够，写入令牌才恢复。

这条恢复链说明为什么 Builder 不可或缺。错误跨越了语言理解、工具协议、CRM 状态、权限和业务修复。任何一个专业角色都能解决其中一部分，仍需要有人把完整影响与重新发布证据连接起来。

什么时候不要做 Agent ​

如果任务路径稳定，规则容易说明，先使用表单、脚本或确定性自动化。Agent 不会让一个已经清楚的流程自动获得更多业务价值，只会增加模型分支和验证成本。

如果输入输出已经结构化，模型通常也不是首选。把字段从一个系统映射到另一个系统，用代码能更准确地表达规则。自然语言界面可以保留，但不必让模型控制底层状态转换。

如果错误代价高、动作不可逆，又无法及时人工复核，应该先限制动作甚至停止自动执行。缺少日志、沙盒、暂停和恢复能力时，也不适合把写权限交给 Agent。

如果团队拿不出代表性样本，无法定义任务成功和失败，增加自主性只会让不确定性更难观察。先由人完成任务并记录变体，往往比直接设计一个开放 Agent 更有价值。

还有一类问题与 AI 无关：重复审批来自组织授权不清，没人使用系统来自激励冲突，冗余录入来自两个部门不愿共享数据。模型可以掩盖摩擦，却不会替管理者解决责任归属与制度层面的问题。

为澄川逐动作选择自主性 ​

一个较弱方案会写：“为了最大化效率，让 Agent 自动完成摘要、需求判断、CRM 更新和客户邮件；重要步骤增加日志。”日志只能帮助事后调查，无法弥补过宽权限、缺少人审和不可逆动作。

一个合格方案会逐项判断：会议摘要可由模型自动生成，但标记为草稿；客户需求只由 AI 提出建议，并显示原句与资料依据；CRM 更新由 AI 准备预览，销售确认后提交；内部跟进任务也先由 AI 准备；客户邮件不交给 AI 发送，只允许准备草稿。

方案还应说明扩大动作权限的条件。只有在字段级评估稳定、工具支持幂等与状态查询、错误可以回退、权限正式批准后，才考虑让 AI 直接执行特定低风险字段的更新。对外承诺不随其他动作一起放开。

你的练习 ​

选一个包含五个以上动作的任务，为每个动作写下：当前执行者、错误代价、可逆性、所需上下文，以及它属于 AI 只建议、AI 准备结果、人批准后执行、满足条件时执行还是在明确边界内自主执行，并写明扩大权限前必须补的证据。至少保留一个确定性步骤和一个完全不使用 AI 的步骤。

然后做一次事故演练：任选一个工具返回“状态未知”，写出系统何时停止、谁核对真实环境、怎样恢复、谁批准重新开放。若答案只有“重试”和“人工处理”，说明工具与人审契约仍不够具体。

本章小结：行动能力扩大了建设对象 ​

Agent 让模型可以根据环境反馈选工具、推进任务，适合那些路径难以提前写死的问题。但用上 Agent 之后，需要纳入质量保障的范围就从一段输出，扩展到整条运行轨迹和最终环境状态。

这就是为什么 Agent 能力越强，工作流设计越要及时跟上：目标、上下文、工具、状态、人审、停止与恢复必须一同设计到位；自主性按动作逐个选择，不做笼统的“整个系统自动”；更简单的系统够用时，就不必强行采用 Agent。

我们现在知道了怎样在三种系统之间选择，却还没有回答一个更早的问题：企业提出的“做一个 Agent”，究竟对应哪项真实工作、哪位用户和哪条可验证基线。下一章将回到现场，把工具愿望改写成值得建设的问题。

下一章：从工具愿望到可验证场景

本章来源与框架边界 ​

确定性自动化、LLM 工作流与 Agent 的区分参考了上述一手资料。逐动作选择自主性、六类外部契约和澄川事故处理均为本书教学整理，不代表外部机构发布的统一标准。