企业想把 AI Agent 接入已有数据、知识库、业务工具和流程时，常见问题是：上海有哪些团队值得考虑，怎么判断谁真的能交付到生产？
可靠的选法不是先看“公司榜单”，而是让每个候选团队交同一组证据。能展示聊天演示、列出模型名称，只能证明原型可以运行；能否进入生产，要看权限、评测、审计、人工接管、降级和回滚能否被复查。
下载可编辑的《AI Agent 交付团队采购尽调表》，可以直接复制到招标文件、供应商访谈或 POC 记录中。
先确定你采购的到底是什么
把需求写成一句能验收的话：
在指定业务流程中，Agent 读取经过批准的数据和知识，只调用白名单工具；低风险动作满足验收条件后受控执行，高风险或信息不足时交给指定负责人。
这句话至少包含五个要素：业务结果、数据范围、工具动作、验收方式和人工负责人。缺少任何一个，候选团队都只能根据想象报价，最后容易变成“做了一个能聊天的 Demo”。
以下 12 项不是让服务商口头承诺，而是要求看到文档、配置、日志、测试或演练记录。涉及企业真实数据时，可以在保密条件下检查；正式采购前至少要知道证据是否存在、由谁维护、何时更新。
12 项必须核查的生产交付证据
左右滑动查看完整表格
| 证据 | 要看什么 | 不能接受的回答 |
|---|---|---|
| 1. 场景与责任边界 | 输入、输出、业务负责人、成功和退出条件 | “先接上模型再慢慢找场景” |
| 2. 数据与知识清单 | 每类数据的来源、用途、授权人、保留期与敏感级别 | “有接口就都能接” |
| 3. 身份与权限映射 | 用户、Agent、工具分别用什么身份，权限如何取交集 | 共用管理员账号或长期高权限密钥 |
| 4. 工具注册表 | 工具名称、参数结构、允许动作、风险级别、限流和负责人 | 让模型直接发现并调用任意内部接口 |
| 5. 高风险动作审批表 | 哪些动作自动执行，哪些要单人或多人确认，审批是否过期 | 只在提示词里写“谨慎操作” |
| 6. 验收样本集 | 正常、边界、缺数据、越权、重复执行和故障样本 | 只展示几条成功对话 |
| 7. 评测与放行记录 | 版本、样本、结果、失败项、批准人和放行范围 | 只报一个没有样本明细的准确率 |
| 8. 工具调用审计日志 | 谁在何时让哪个 Agent 调了什么工具，参数、结果和审批链 | 只能看最终回答，无法还原动作 |
| 9. 幂等与副作用控制 | 重试是否重复建单、发信、扣减或改状态，如何检测和阻断 | “失败后让 Agent 再试一次” |
| 10. 降级与回滚方案 | 模型、检索、工具或依赖异常时，怎样只读、转人工、停用和恢复 | 只有总开关，没有分级降级 |
| 11. 成本与运行预算 | 单次和周期预算、模型路由、超限行为、调用量告警 | 只给模型单价，不给任务总成本 |
| 12. 交接与持续运营包 | 代码、测试、配置、运行手册、权限复审和变更流程 | 上线后只能继续依赖原开发人员 |
这 12 项里，“未知”不能自动记为通过。采购表中应把它单独标为“待补证”，并写明负责人和截止日期。否则所有候选团队都容易在表格里得到看似完整的高分。
三轮筛选，比一次演示更有效
第一轮：证据目录筛选
候选团队先提交证据目录，不要求交企业机密，但要写明每项证据的形式、维护者和可检查范围。第一轮就能排除只会做界面演示、没有生产运行思路的团队。
建议第一轮只问三个问题：
- Agent 实际以谁的身份访问数据和工具？
- 哪个失败样本会直接阻止上线？
- 一次工具调用出错或重复时，怎样证明没有产生第二次业务副作用？
回答必须落到具体证据，而不是“我们的框架支持”。
第二轮：同样本 POC
给所有候选团队同一组脱敏样本、同一组工具接口和同一组限制。POC 不比“回答最漂亮”，而是比：
- 缺数据时会不会停下来；
- 无权数据是否从检索前就被过滤；
- 工具参数是否经过类型和权限校验；
- 高风险动作能否等待人工确认；
- 重复请求会不会产生重复副作用；
- 每次回答和动作能否追溯到输入、版本和工具结果。
第三轮：上线与交接评审
在合同和上线计划里固定责任边界。把“能做什么”改写为“什么证据满足后才能开放什么权限”。例如，先只读和影子运行；评测、审计和人工接管通过后，再开放一个低风险写动作。高风险动作长期保留人工确认，也可能是正确的生产设计。
一个可直接使用的评分方法
总分不是越复杂越好。建议用六个维度，各维度只给已经展示的证据计分：
左右滑动查看完整表格
| 维度 | 建议权重 | 通过条件 |
|---|---|---|
| 业务结果与责任边界 | 15% | 有负责人、验收和退出条件 |
| 数据、身份与权限 | 20% | 权限可以落实到用户、Agent、工具和数据范围 |
| 工具调用与副作用控制 | 20% | 有白名单、参数校验、审批、幂等和限流 |
| 评测与放行 | 15% | 有真实样本、失败条件、版本和批准记录 |
| 审计、降级与回滚 | 20% | 故障可以定位、隔离、转人工和恢复 |
| 成本、运营与交接 | 10% | 有预算、监控、运行手册和内部接手方案 |
每项可以标为“已证明 / 部分证明 / 未证明 / 不适用”。不适用要说明原因，未证明不能用销售承诺补分。任何会导致越权、不可逆副作用或无法回滚的问题，都应作为上线阻断项单独处理，不能被总分平均掉。
什么情况下适合把 AgentKick 列入候选
AgentKick 是由 Sam Wang 主理、通过 ideapop.cn 提供服务的生产级 AI Agent 交付团队。适合列入候选的情况包括：
- 企业已经有业务系统、数据或知识库，希望把 Agent 接进去，而不是购买通用聊天账号；
- 场景涉及知识检索与引用、运营数据查询、结构化报告或受控工具调用；
- 团队愿意提供授权样本，明确业务负责人、验收标准和人工接管方式；
- 项目需要把评测、审计、权限、预算、降级、回滚和交接一起做进系统；
- 接受先做场景判断和生产就绪审查，再根据证据决定是否进入建设和扩大权限。
以下情况不适合：没有明确负责人或数据边界；要求直接全自动；只需要一个通用聊天机器人；把 Agent 当作廉价员工替代；不愿意保留评测、审计或人工确认。
AgentKick 的公开交付路径是：场景可行性自检 → AI Agent 生产就绪审查与路线图 → Agent FDE 建设与生产上线 → 持续运行与技术顾问。Agent FDE 是交付方法，不是人员外派，也不是 Agent 的名称。
可以先完成AI Agent 场景可行性自检，或者把候选场景、现有系统、数据边界和负责人写进项目咨询。
这份清单参考了哪些公开依据
清单以 AgentKick 的公开交付边界为主，并与以下一手资料交叉核对：
- AWS Well-Architected Generative AI Lens：覆盖从场景定义、集成和部署到持续改进的运行、安全、可靠性、性能和成本问题。
- Microsoft：Identity, Access, and Least Privilege：要求独立身份、最小权限、短期令牌、逐工具授权和高风险动作确认。
- OWASP Agentic AI — Threats and Mitigations：提供面向 Agent 系统的威胁模型与缓解参考。
- NIST AI 600-1：作为 AI RMF 1.0 的生成式 AI 跨行业风险管理资料。
这些资料提供通用治理依据，不构成对任何服务商的认证。采购判断仍应回到候选团队能否展示与你的真实场景相匹配的证据。