智能体本身很少是难点。在确定任何公司级 AI 智能体项目的范围之前，我都会先做以下准备度检查。

我在 HubSpot 和 Salesforce 领域深耕了 10 多年，并将 3 家服务公司的业务规模扩大到七位数。最近，我一直在为工程、太阳能/能源和物业管理公司开发 AI 语音/短信租赁智能体，以及 Airtable/Make/Zapier/n8n 集成。最一贯的经验是：导致项目失败的，往往不是智能体本身，而是它所处的环境。因此，在为任何规模超过试点的项目报价之前，我都会从五个方面进行就绪度检查。其中很多做法都受到我商业合伙人的影响，他在 IT 和数据/云托管服务领域有 30 年的经验。1. 基础设施 这套系统运行在谁的云环境/租户中，账户归谁所有？这决定了合作结束时如何交接。列出智能体会读取或写入的每一个系统，以及各自的身份验证方式和速率限制。有沙盒环境吗？如果没有预发布 CRM 环境，你的测试就会在生产环境中进行。2. 数据 对于智能体涉及的每个字段，哪个系统是权威数据源？在物业管理领域，房源可租状态常常同时存在于物业管理系统（PMS）、电子表格和某个人的脑子里，而且三者并不一致。数据过时到什么程度，智能体就会给出错误答案？谁负责修正错误数据，这是否属于项目范围？3. 网络安全 它会处理哪些个人身份信息（PII）或录音？在美国，语音/短信还涉及同意规则（TCPA、退订）。API 密钥应遵循最小权限原则，密钥等机密信息应保存在密钥保管库中，而不是工作流节点里，日志也应排除敏感字段。传入内容（电子邮件、短信、表单字段）可能带来提示词注入。要假设有人会尝试这样做。4. 治理 谁批准对提示词、工具和模型的更改？人工介入的门槛是什么：哪些操作需要人工批准？紧急停用开关、审计日志、数据保留，以及允许使用哪些模型供应商。是否需要数据处理协议（DPA）？5. 实施风险 在这里，“出错”的代价是什么？漏掉一个潜在客户是一回事。向潜在租客报错租约条款则是另一回事。回滚计划、升级处理路径，以及发生问题时通知谁。最终产出是一张单页表，按每个领域标注红/黄/绿状态。它会成为工作说明书（SOW）的第 0 阶段，范围明确为短期、固定费用的付费前期调研。红色项要么成为由客户负责满足的前提条件，要么成为额外收费项，而过去大部分项目范围蔓延都源于这些地方。附带的效果是：它将对话从“你能做一个机器人吗”转向“你能安全地运行这套系统吗”，而 IT 和安全人员对此的反应会截然不同。你们的开发前检查清单里，还有哪些是我遗漏的？我尤其好奇，对于尚未制定 AI 政策的公司，大家如何处理模型/供应商审批。