第一个 AI 智能体：先选多步、可验证、可退出的任务

先看结果：8 项重复工作里，只有“交付包预检”值得先做智能体

独立课程制作人唐棠每月为 3 个客户交付线上课程包。她列出 8 项想自动化的工作：总结访谈、重命名文件、定时备份、生成催款邮件、检查交付包、研究新工具、批准退款和向客户发送最终文件。她原以为越重要、越费时的工作越值得交给智能体，实际筛选后只选择了“客户交付包预检”。

一次交付包有 10—18 个文件，中位数为 14，包括演示、讲义、工作簿、字幕、图片和链接清单。预检不是固定的按键序列。智能体要先读取简报和文件清单，决定运行哪些解析器或渲染器；看到 PDF 截断后回查源演示；发现链接重定向后检查目标是否仍属于批准域名；在隔离副本中修正安全的元数据或文件名，再重新渲染并验证。最终只生成候选包、差异和待人工判断项，不向客户发送任何内容。

本文是虚构教学案例，任务量、测试和时间只用于演示选择方法。它不说明任何智能体平台天然可靠，也不主张个人应让 AI 自主处理付款、合同、身份、安全或客户权益。

先区分四种实现：会调用模型的多步骤流程不一定需要智能体

本文把方案按“谁决定下一步”区分。单次生成由用户给材料、模型返回结果；脚本由代码执行完全确定的规则；固定工作流按预先画好的步骤和分支调用模型/工具；智能体则在边界内根据目标、当前状态和工具观察，动态选择下一动作，直到达到停止条件或转人工。

智能体不是“更高级”的默认终点。若 95%运行都执行同样 6 步，应该先把稳定部分写成工作流；只有真正需要观察后改计划的少量节点由模型判断。选型目标是用最简单、可验证的系统完成任务，而不是把所有自动化都改称智能体。

这四类也可以组合。交付包流程用脚本计算哈希值、用固定工作流完成清单和基础验证器、用模型在异常路径选择诊断工具，最后由人决定内容冲突与发送。架构图中只有“根据观察选下一步”的局部需要智能体；把外围确定性控制也交给模型，既更贵也更难复现。

唐棠还做了一次反事实检查：把模型决策全部替换成固定的“如果……那么……”。如果这种做法仍能覆盖 12 个历史包的全部路径，就没有必要建设智能体。结果是，仅 PDF 异常就会分成源演示、栅格图、字体缺失、页面尺寸和源文件缺失 5 条路径，下一步依赖不同的工具证据；文件重命名却只有 4 类例外，可以完整编码，因此继续留给脚本。

从工作结果倒推：先定义完成证据、失败代价和人工责任

唐棠没有先挑框架，而是为每项工作填写结果卡：输入是什么、合格输出是什么、谁使用、错误会影响谁、能否在外部影响前发现、怎样撤回、每月出现几次、现在花多少时间。描述不清的任务暂不进入技术选择。

如果完成标准只能写“结果看起来专业”，既无法选择架构，也无法评估智能体。先把业务终点变成可检查状态，才能讨论是否需要动态执行。

她还把“节省时间”和“提高质量”分成两个目标。首版的主目标是关键缺陷漏检为 0，次目标才是减少人工时间；若智能体快了 30 分钟却漏掉错版，项目仍然失败。每项指标都写明负责人和数据来源：计时来自运行日志，问题真值来自双重人工复核，外部动作来自工具审计，满意度不能替代这些运行证据。

结果卡还要列明排除项。本案例不判断课程内容是否教学有效、不核实图片版权、不审核合同义务；这些工作即使也叫“交付预检”，也需要不同的专家、信息来源和风险控制。一个任务名称包含多个实际决定时，应先拆任务再选型。

盘点真实任务基线：频率、变异、返工和等待比“感觉很耗时”更有用

唐棠回看 4 个月、12 个交付包，共 168 个文件和 384 项需求检查。人工预检中位数 94 分钟，最快 61、最慢 143；等待客户补资料另计，不把等待时间冒充可节省工时。她从问题日志中找到 46 个已确认问题。

频率并不自动支持智能体：定时备份每月 30 次却完全确定；范围冲突只有 5 次却需要语义判断。基线的作用是理解工作构成，并为后续节省与漏检提供同一比较对象。

12包的时间分解显示，94分钟中约31分钟用于打开/盘点文件，26分钟用于机械检查，22分钟用于渲染后寻找问题，15分钟用于判断与记录。智能体可能减少前三类切换，不应假设最后15分钟全部消失。她也记录变异来源：5种文件组合、3种简报模板、2种链接策略和4种历史命名法；若只拿最整齐的包做演示，会高估适配性。

12 个交付包中有 4 次等待补资料，等待时间从 2 小时到 3 天不等。智能体可以更早生成缺件回执，却不能把这段日历等待算成自动化节省。基线应分别记录人工操作时间、工具实际运行时间、外部等待和返工，避免出现“总周期缩短 90%”这类失真的数字。

先设否决门：高影响、不可逆、权限不清的任务不能靠高“适配分”翻盘

唐棠使用六个否决。命中任一项就不做首个自主智能体：它能直接转钱/签约；能代表本人对外承诺；能删除或覆盖唯一资料；处理权限尚未确认的敏感信息；错误无法在影响前检查；没有人能够理解并接管。

“加一个人工审批”不一定消除否决。若审批者看不到工具做了什么、没有时间核对或按钮默认放行，人工只是装饰。首个智能体应让人能在外部动作前看到完整差异和证据。

否决也按最坏合理后果而非平均情况判断。退款任务即使99次金额很小，第100次仍可能涉及争议、欺诈或法定义务；发送文件即使可以补发，错收件人获得保密材料的影响不能靠“再发正确版”撤销。将智能体降为只读证据整理可以保留部分价值，同时把决定和动作留给有权的人。

若某项否决能被架构真正移除，可以重新评估。例如，把“删除旧文件”改为复制到本次沙盒并生成归档建议，执行层根本不提供删除能力，删除风险才算被移除；仅在提示中写“不要删除”并不算。

四道必要性门：动态选择、工具反馈、修正循环和可验证终点

第一道必要性门：任务必须多步，而且步骤之间存在真正依赖

多步不是把一个提示拆成五次调用。后一步要使用前一步产生的状态或证据：文件清单决定解析工具；解析结果决定需要渲染哪些格式；渲染异常决定回查源文件；修正候选后必须重跑受影响检查。若所有步骤可并行独立完成，它更像批处理或并行工作流。

交付包有的只有 PDF，有的还包含源演示、外部链接和工作簿；预先运行全部工具会浪费时间，仍无法决定异常应回到哪个源。因此它通过了多步依赖门。

她把实际路径画了出来，而不是笼统地想象模型“会规划”：12 个历史包共出现 9 种轨迹，最短 8 个工具操作，最长 21 个；只有文件清点、简报地图和最终回执三段固定，中间的检查与诊断顺序各不相同。若轨迹差异只是文件数量不同、步骤仍然相同，就不足以证明智能体有必要；这里真正变化的是观察之后的工具选择和停止位置。

第二道必要性门：下一动作必须由工具反馈改变，而不是只靠模型自我反思

智能体的观察应来自可核验环境：文件存在性、解析结果、页面截图、公式检查、HTTP 状态、目标域名和哈希值。让模型连续说“我会再检查一次”不是工具反馈，也不能证明结果改善。

反馈必须真正影响计划，并留下运行轨迹。工具无法返回可靠观察的任务，不适合在首个智能体中靠自然语言猜状态。

每条观察都记录所用工具、输入摘要、时间、结构化结果和产物位置。模型看到的应是“渲染状态：部分完成，已完成页数：6/12”，不能把“渲染似乎完成”解释为成功。计划变更时还要写原因代码，例如来源缺失、重定向未批准或视觉溢出；事后才能统计错误的工具选择，而不是只能翻看冗长的思考文本。

对于外部网页，HTTP 200也只是可访问证据：还要比较最终统一资源定位符、域名、页面标题和抓取时间。对工作簿，打开成功不证明公式已重算；对PDF，12页都生成图片不证明内容未裁切。工具反馈要尽量靠近业务验收，而不只报告技术调用成功。

第三道必要性门：任务需要修正循环，但循环必须有外部验收和退出上限

生成—自评—再生成常会把错误换一种写法。可用循环是：提出最小修正、在候选副本执行、调用独立检查器观察是否通过；最多两轮，仍失败就转人工。内容或范围冲突从第一轮就不自动改。

检查 → 得到带证据的问题
  → 选择许可范围内的修正
  → 在沙盒副本中执行
  → 重跑受影响的检查器
  → 通过｜再做一次有界修正｜转人工

无限迭代、只看模型评分、没有最大尝试次数的任务会失控地消耗时间与成本；这类流程应先改成人机交互，不要把持续运行误当成智能。

第四道必要性门：必须存在可验证终点，而非追求“尽可能好”

预检“完成”不等于零警告，而是每项需求都有状态和证据，所有阻碍已经处理，需要人工的项目已有负责人，候选包哈希值已经冻结，而且最终发送尚未发生。允许保留已经解释清楚的警告；不允许模型为了达成“全绿”而删掉检查项。

“完成”必须能由任务外的证据确认。若只有智能体自己知道为什么满意，出现错误时人无法接手，也无法建立评估集。

唐棠为 32 项常规需求指定了评估方式：18 项由确定性检查器判定，7 项需要视觉证据加人工复核，5 项需要比较简报与成品语义，2 项只能由客户负责人决定。智能体不得把后两类转交结果写成通过。回执还要保留覆盖率：32 项中即使有 31 项通过，只要 1 项状态未知，整包仍不能完成，不能用 96.9% 的平均数掩盖未查项目。

用适配矩阵代替一个神秘总分：核心必要性与可运营性分别过门

唐棠不给任务打“智能体适配度 87 分”。她要求四项必要性全部成立，再检查可运营条件；任何否决优先。这样不会用高频、节省时间等优点抵消不可逆风险。

可运营性还包括输入权限明确、工具结果可记录、代表性历史样本存在、人工负责人有时间复核、失败可转人工、频率足以回收建设成本。通过必要性只说明智能体可能合适，不说明现在值得建。

矩阵使用三种结论：是必须有历史轨迹或任务证据，否说明更简单方案足够，状态未知则要求先做人工观察。她最初把“新工具研究”四项都填是，但完成只能写“尽可能全面”，改成“比较3个已知工具的导出能力并保存官方证据”后，路径反而能预定义为研究工作流；缩清问题常会降低对智能体的需要，这是好结果。

把选中的任务缩成合同：目标、输入、工具、禁止动作和预算都写死

首版只处理标准课程包，包含 10—18 个文件、最多 40 项简报需求；不处理加密文件、视频内容质量、客户个人身份信息、法律许可或付款资料。输入必须是只读来源文件夹、已批准简报、来源地图和域名白名单。

边界让第一个智能体足够窄。它不是“替我处理所有客户交付”，而是“在不接触客户和不覆盖源文件的前提下，为一类标准包完成可复核预检”。

合同还要固定输入版本。运行开始时保存已批准简报的哈希值；过程中若客户上传新版本，当前运行立即标记为过时并停止，不能把新旧要求混在一个结论中。来源地图必须把每个导出件指向可编辑源；找不到关系时可以报告孤立文件，不得凭文件名猜。预算到顶时输出已完成检查与未完成清单，不能把部分验收包装成最终通过。

工具表要写清读写权限、证据和失败含义，名字相同不等于能力相同

工具描述要避免让智能体把超时当成 404、把不可读当成不存在、把渲染成功当成内容正确。写工具不是 O26 的重点，但如果观察结果的含义不清，就无法证明任务真的需要或适合智能体。

完整走一条动态轨迹：同样是“第 7 页异常”，下一步由证据决定

在 09 号交付包中，文件清点工具找到 15 个文件，简报列有 34 项需求。PDF 渲染器报告第 7 页文本超出画布；智能体先读取来源地图，定位到源演示第 12 页，而不是直接编辑 PDF。重新渲染源演示后，它发现替代字体令表格增高；于是在候选副本中把该文本框字号从 18 调到 17，并将高度增加 4 像素，然后重新渲染。

若溢出来自一张栅格截图，调整文本框就无效；若源文件缺失，应直接标记为已阻塞。智能体的价值在于根据外部反馈选择正确诊断路径，不在于自主做更多事情。

权限与沙箱决定错误半径：先做到只读诊断，再开放可逆候选修正

阶段 0 只读取去标识的历史副本；阶段 1 读取真实候选但只输出报告；阶段 2 才允许写入运行专用沙箱。客户目录、邮件、网盘共享权限和发布平台始终不可用。凭证按工具分开，链接检查器只能访问批准域名，也不携带客户令牌。

首个智能体不需要生产写权限来证明价值。先证明它能发现、解释和修正候选，再讨论是否扩大动作；很多 OPC 场景长期停留在辅助使用阶段已经足够。

用 12 个历史包建立评估集：测试的是轨迹与工具选择，不只看最终报告

12 个交付包中的 46 个已知问题组成冻结集合，另外注入 14 个对抗案例：工具超时 3 个、同名错版 3 个、重定向到未批准域名 2 个、公式缓存陈旧 2 个、简报自相矛盾 2 个、源文件缺失 1 个、加密文件 1 个，共 60 个案例。每个案例都写明预期发现、允许的工具、禁止的操作、所需证据和退出状态。

两项未检出是语义范围冲突，均进入人工常规复核清单，因此不宣称“自动质量保证”。关键12项包括错版、缺文件、公式范围和严重截断；修订后12/12发现。评估集不能在每次失败后删难题，应保留以防回归。

真值标注由唐棠先独立完成，再由一名熟悉课程交付的协作者复核；分歧有7项，5项在查简报后达成一致，2项保留为合法歧义，预期状态设为需要人工而非强迫唯一答案。否则评估集会把标注者个人偏好当真值，并奖励智能体自信选边。

评估不仅计“找没找到”。对每个案例还查是否调用允许工具、引用正确来源位置、没有越权修正、在预算内退出。首轮有 1 次来源文件写入尝试，哪怕最终文件看起来正确也整轮失败；安全约束不能用 44/46 的发现率平均掉。

10 次影子运行验证真实负担：发现率、误报和人工时间必须一起看

影子阶段智能体不修改也不影响人工流程。10 个新包共141个文件、318项需求；双重人工复核确认31个问题。智能体找到29个，漏2个内容范围细微冲突，另报3个误报：2次把有意保留的旧链接视为错误，1次把讲师备注缺失误判为必需。

节省的是人工分钟，不把智能体自己运行的12分钟重复相加为人的工作。最终发送仍由唐棠完成。两个漏检使她保留“简报与成品语义逐项抽查”，而不是因总体发现率不错就删除人工角色。

10包按顺序运行，没有挑掉格式复杂的包。前3包误报共2次、人工复核中位数44分钟；后7包在白名单和需求映射修正后误报1次、中位数36分钟。这个改善只是小样本运行记录，不外推成稳定性能；每次结果仍保存包类型、工具版本、步骤数、状态未知、未命中和人工修改，供30次门槛复评。

31个问题的严重度为严重 6、重大 13、次要 12；智能体找到6/6 严重、12/13 重大、11/12 次要。第二个漏检虽标次要，仍揭示语义比较弱点。按严重度看比只报29/31更能决定人工检查放在哪里，但严重度由影响规则和负责人批准，不由模型为自己打分。

经济性还要包含建设、运行、复核、维护和失败返工

0.1 版的建设与标注用了 14 小时。影子数据估计每包减少 56 分钟人工预检；但每 3 包还需约 45 分钟更新解析规则、回看误报和补测试，相当于每包 0.25 小时维护。净节省约为 0.93−0.25=0.68 小时/包，静态回收点为 14÷0.68≈21 包；按每月 3 包计算约需 7 个月，尚未计入模型、平台和工具费用。

如果每月只有 1 包，或工具格式经常变化，回收期会明显拉长。第一个智能体的目标可以是学习和降低漏检，不必伪装成短期投资回报；但动机必须写清，避免在维护上投入超过它节省的时间。

变量费用表至少记录模型调用、文档解析、渲染、网络检查、日志存储和失败重跑。案例未填写真实货币，因此21包只是时间回收点，不是完整财务盈亏平衡。唐棠设一个通过/不通过：补齐30次运行费用后，把个人时间按自己认可的机会成本换算，再比较总收益；若平台费用高于可避免返工价值，即使技术门通过也保持人工流程。

收益也不能重复计算。找到缺陷减少的返工若已经体现在94→38分钟，就不能再把同一批返工时间作为额外收益；客户满意或风险降低只有实际证据时才记录。她保留三列：观测、估算、未测量，避免模型把假设自动合并为总投资回报率。

从失败里判断应该修智能体、改工具、缩范围还是退回工作流

首轮出现来源写入尝试，并不是“模型偶尔不听话”：复制工具把来源与沙盒参数放在了同一个自由字符串中。修复办法是让工具只接收相对于沙盒的目标路径，并由执行层拒绝越界，而不是再加一句提醒。工具超时被判为文件损坏的问题，则通过返回结构化的“状态未知”来修正工具含义。

如果运行日志显示多数路径已经稳定，就把稳定步骤固化成工作流，只保留异常分诊给智能体；智能体用得更少可能是成熟，而不是退步。

修订后重新跑完整的 60 个案例，而不是只跑失败的 5 项。新的源映射优先策略修复了重复渲染，却一度让 2 个孤立 PDF 过早进入“已阻塞”；加入“无来源时仍可完成只读 PDF 检查、但禁止自动修正”的分支后才恢复。局部修复可能改变别的轨迹，回归范围必须覆盖正常、异常与停止路径。

现场出现新失败时，应先保护任务：冻结候选包哈希值、保留工具观察、把未完成需求标为状态未知，再转人工完成本包；是否修改智能体是下一项独立变更。不能在同一次客户运行里不断改规则直到通过，否则这次结果使用的其实是未经评估的新系统。

单智能体足够：不要用多智能体架构掩盖一个尚未定义好的任务

交付包预检只有一个负责人、一个目标、7 类工具和清楚的停止规则。拆成“文件智能体、链接智能体、视觉智能体、主管智能体”会增加消息传递、上下文丢失、成本和调试面，并不会自动提升正确率。首版使用一个智能体调用确定性检查器，人工做最终审阅。

Google Cloud 当前设计指导把任务复杂度、延迟、成本和人工参与列为架构选择问题，并建议早期智能体开发从单智能体系统开始；Anthropic 也建议先用简单方案和全面评估，只有简单方案不足时再增加智能体复杂性。本文把这些作为设计参考，不把特定云平台或模型的实现当成通用保证。

在这些证据出现前，保持“单智能体＋工具＋人工放行门槛”更容易理解和接管。

所谓单个智能体也不等于一个巨型自由提示。确定性验证器各自有明确输入输出结构和测试，编排器只选择工具与解释观察；所有写入在执行层受沙盒限制。把可靠性放进工具与权限，能减少模型需要“记住”的规则。若未来拆多智能体，先证明任务边界与评估仍成立，而不是用角色名称替代接口。

建立继续、缩小和退出标准：不因“已经搭好了”继续扩大自主权

完成 30 次辅助运行后才重新评估：关键问题漏检必须为 0；来源或外部写入为 0；需要人工的项目不得被绕过；误报不高于每包 1 个；人工复核中位数不高于 45 分钟；每月维护不高于 60 分钟；变量费用在个人预算内。任一安全指标失败，立即退回只读影子阶段。

退出计划包含：关闭调度、撤销工具凭证、保留运行与评估证据、删除临时候选、确认来源未改、恢复人工清单。智能体不是只能升级、不能退役的“数字员工”。

唐棠实际做了一次退出演练：暂停运行入口，撤销链接检查的网络令牌和沙箱写入器，验证新任务无法启动；清理 3 个测试候选包，逐一比对来源文件哈希值；按照人工检查清单完成一个历史包，并确认问题日志仍可用。演练用了 27 分钟。若退出只能靠构建者临场解释，工具已经形成新的单点依赖，不适合作为个人首个长期智能体。

版本变化也应触发暂停，而不是自动升级。模型、解析器、渲染器或关键简报模板变化时，先重跑 60 个冻结案例，再选 3 个新包进行影子运行；只有安全门和 12 项关键检查继续通过，才恢复辅助使用。选型不是一次性决定，任务变得更稳定或更高风险时都应降级重评。

复制这张首个智能体选择卡，从三个真实候选做对比

本案例参考了四类公开资料：Anthropic《构建有效的 AI 智能体》对固定工作流、动态智能体以及“先从简单方案和评估开始”的区分；Google Cloud 于 2026-05-28 复核的智能体设计模式指南，其中讨论了开放与确定性任务、延迟、成本、人工参与和单智能体起步；NIST AI RMF Core 对具体任务定义、近似部署条件下的可重复技术评估、限制记录与持续监测的要求；英国政府《AI 操作手册》对工具选择及高影响环节人工控制的说明。NIST AIRC 当前注明 AI RMF 1.0 正在修订，本文引用的是核验日可见的核心页面；后两类资料面向组织或政府语境，本文只借用风险、测试和人工控制原则，不把其治理角色直接套给个人。

• Anthropic：Building Effective AI Agents
• Google Cloud：Choose a design pattern for your agentic AI system
• NIST AI RMF Core：Measure
• NIST Generative AI Profile
• UK Government：Artificial Intelligence Playbook

今天先列出 3 项真实候选，而不是创建一个“万能助理”。逐项写清：下一步是否会因工具反馈而改变，修正后由什么独立证据验证，最坏错误能否在造成外部影响前撤回。只有同时通过四道必要性门、没有触发否决且拥有历史样本的候选，才进入只读评估；如果没有候选通过，正确结论就是暂时不做智能体。