智能体落地手记：把 AI 从「能聊天」做到「能交付」的六件事

大模型竞赛的下半场比的不再是参数，而是谁能把能力装进真实的工作流。但从 demo 到生产，中间隔着的往往不是「换个更强的模型」，而是一整套不起眼的工程。下面这六件事，是决定一个智能体能不能长期跑下去的关键，按重要程度排序。

一、把任务边界写成可验收的契约

智能体最常见的失败不是「不会做」，而是不知道什么时候算做完。开工前必须固化三样东西：输入边界（哪些数据可以喂、哪些必须脱敏）、输出契约（格式、字段、长度、引用来源）、验收标准（人或者一段确定性代码能判定通过与否）。

实操建议：每个任务配一个 definition_of_done 清单，让模型在结束时逐条自检并输出勾选结果。这份清单同时就是最好的 prompt 骨架——比「请认真完成」有效一个数量级。

二、工具权限：默认拒绝，按需授予

能读文件、能发请求、能改数据库，是三种完全不同风险级别的能力。给智能体的工具集要遵循最小权限，并且把「写操作」和「对外可见操作」单独设闸：

•读类工具可直接开放，但要限制路径与域名白名单；

•写类工具必须带确认环节（人工批准，或只在影子环境执行）；

•对外可见操作（发消息、发布内容、下单）一律要求幂等键，防止重试造成重复骚扰。

这一条在多渠道机器人上尤其具体：撤回、主动推送、群管理这三类动作，权限和频控都要单独设计，不能共用一把钥匙。

三、上下文预算：不是塞得越多越好

长上下文是能力，也是成本与噪声来源。有效的做法是把上下文分层：常驻层（角色、约束、工具说明）、任务层（本次目标与验收标准）、检索层（按需拉取的片段，带来源与时间戳）。检索层一定要带时间戳和出处，否则模型会把过期事实当作现状输出。

一个容易忽略的细节：把「已知的不确定项」显式写进上下文，比让模型自己猜测要安全得多。凡是无法核对来源的内容，宁可在产出里标注「未验证」，也不要让它以肯定句出现。

四、失败补偿：假设它一定会失败

外部调用会超时、会被限流、会返回半截结果。可靠的智能体不是不出错，而是出错后系统状态仍然一致。三条经验：

1.写操作三态化：已提交、已受理但未确认、已回滚。中间态要能被后续动作收敛，而不是永远悬着。

2.标识符不可截断。为了省字段长度把外部平台的 ID 截到一半存起来，等到要撤销、要引用时会发现凭据已经失真——这类问题排查起来最费时间，因为错误提示通常会指向别处（比如「参数无效」）。

3.失败必须可见。错误原因、上游原文、发生时刻要能一眼查到；只在控制台打日志的方案，等到线上复现时等于没有。

五、可观测：让每一次调用留下线索

智能体的链路比传统接口长：一次用户请求可能触发检索、三次工具调用、一次重排、再一次生成。没有链路追踪，成本归因和效果调优都无从下手。最小可用配置是四件事：请求 ID 贯穿全链路、每次工具调用记录输入摘要与耗时、Token 与费用按任务归集、结果质量抽样回标。

把这四项当成上线门槛而不是后续优化项。等积累了几千次调用再补埋点，那批数据就永远分析不了了。

六、成本闸门：给自主性装上预算

自主性越高，成本方差越大。给每个任务设定三重上限——最大步数、最大 Token、最大墙钟时间，任一触顶就带着「已完成到哪一步」退出，而不是静默失败。再叠一层全局预算闸：按天/按渠道限额，接近阈值自动降级到更小的模型或排队执行。

一张自检表

模型每三个月换一代，但这六项工程约束的有效期以年计。把智能体做稳的人，靠的从来不是追最新模型，而是把边界、权限、上下文、失败、观测、预算这六件事做成默认动作。

如果你正在把某个流程改造成智能体，欢迎在评论区说说卡在哪一步——多数时候，缺的不是模型能力，而是上面六条里的某一条。