密钥和工具调用进模型之前，门禁放在哪？

演示里他先问 JFrog Artifactory 有哪些制品。Artifactory 是存放构建产物的制品库。他在本地和 Slack 机器人上各跑了一遍，问题不变。优化器关掉时，本地这一问在字幕里记成大约 24000 token；打开后再跑同一句，大约 2400 token。Harish Gaggar 在 Credit Karma 负责 AI 分析基础设施。他把这组差额放回生产：代理进集群之前，注册、网关、审计和脱敏要先在。

原始来源：Paving the Road to Production: Governed Enterprise AI Agents — Harish Gaggar, Credit Karma。中文深度整理，非逐字翻译。本文依据 YouTube 自动生成的英文字幕，专有名词和数字可能有识别误差。

生产失败从缺控制开始

他自报是 Intuit Credit Karma 的高级资深软件工程师，拥有并建设 AI 分析基础设施和服务，也做顾问、写作，并在一些组织的项目委员会里指导青年研究者。议程按顺序是：智能体进生产的障碍、架构、自建 MCP 服务和 MCP 网关、网关上的监控、智能体框架、记忆、追踪与评估、在进大模型之前拦住个人敏感信息和密钥，以及用上下文优化省 token。MCP 是模型上下文协议，让模型按约定调用外部工具。Token 是模型计量文本的单位。

生产里大量代理失败，是因为基础控制没放上。问题被他排成一串。代理有没有先到网关，用正确的身份源认证，再被转到该去的 MCP 服务。MCP 服务里有没有能执行这次查询的工具。每条查询有没有被追踪，回答质量有没有评估。对话拉长到很多天，还记不记得先前问过什么。有没有办法少烧 token。密钥会不会流进大模型、追踪、链路或记忆库。这场分享不演示一个神奇代理。他讲的是可以自己搭的框架。

第一块是智能体框架。他们选用 LangChain 社区的 LangGraph，按问题做成任务节点，便于插入市场上的插件、技能和提示。第二块是 MCP 网关。代理或它的服务账号发起调用时，先在网关完成认证，再转到对应的 MCP 服务。第三块是自己的 MCP 服务，里面放对的工具，并对实际操作做审计。旁边还有拦截敏感信息、把追踪和评估存进云、按线程和检查点处理记忆，以及在查询送出前优化上下文。

节目没有给出 Credit Karma 生产环境里的事故率，也没有给出已上线代理的数量。LangGraph 是他们选定的实现，节目里没有做框架横评。

门户一次生成仓库和身份

本地开发先注册。说清用例、它属于哪条业务，系统给出代理 ID。内部开发门户再收下这些字段：用例、ID、框架（LangGraph、LangChain 或其他）、语言（Python 或 TypeScript）、技能或提示。提交之后，门户创建的仓库里同时有 LangGraph 代理、记忆、追踪评估、上下文优化和敏感信息拦截。

开发者常常只照顾助手工具默认的那一两块框架。公司把这些框架做成一致、集中的一套，结果才看得见。开发者克隆仓库，把代理打成 Docker 镜像和容器，用查询测输入输出。追踪可以落在本地记忆，也可以用云上的 span 评估器。追踪和评估可进 SQLite 或 BigQuery。本地跑通，再提 PR。两个批准之后进入 CI/CD。

PR 会先把代理登记进中央注册表。注册表给出链接，用来看全部追踪。流水线把本地那个容器做成生产镜像，扫描漏洞，安全通过后放进镜像仓库。编排平台把它部署到 Kubernetes 集群的指定命名空间。门户同时按名字建出生产资源：工作负载身份、记忆库、追踪和评估表、代理的密钥管理。编排器部署时，绑定已经在。他称为 K 到 GSA 的绑定。Kubernetes 侧的身份接到 Google 服务账号，代理知道该以谁的身份去访问那些资源。之后代理再去连其余端点，例如 AI 网关、MCP 服务、他称为 length fuse 的追踪，以及其他 API。

length fuse 在字幕里没有展开，本文不把它改写成某个市售产品名。两个批准和漏洞扫描是流程描述，节目没有给出平均等待时间。

气隙环境里，调用先过网关

外部 MCP 服务可以用。气隙环境里他强烈建议自建。气隙指网络与外部隔开。实现上他用 fast MCP 的服务包或封装，在里面做一组工具。每个要进生产的工具，必须经过内部安全团队审查，只放行被授权的工具。过滤、限额，以及不该进大模型的字段，在这里挡掉。流量从 MCP 客户端到网关再到服务，无论来自用户还是服务账号，都要先在网关认证，才能碰到工具。

网关也可以自建，同样针对气隙。本地的代码助手或代理提交第一次查询时，向网关发一次认证。网关把会话状态放进 Redis，把 JWT 访问令牌还给客户端。JWT 是带签名的令牌。客户端凭它知道该叫哪一个 MCP 服务。接着它把工具调用发到某个命名空间下的 MCP，例子是 Artifactory 或 GitHub，并带上 Bearer JWT。网关认出命名空间，解开 JWT，把用户令牌附上，转到对应的 MCP 服务。服务按用户被授权的范围去调下游 API，交换 ID 令牌，再把结果包成网关能收的载荷，最后回到客户端。

他要的是一个集中的认证和路由枢纽。代码助手或代理经网关和 MCP 服务到达端点。端点不留绕过网关的直接访问。

这一段是架构走查。字幕没有给出网关的请求规模、令牌有效期或失败重试。GitHub 与 Artifactory 是举例的命名空间。

日志、追踪和延迟分三路存

没有持续监控、评估和反馈，AI 代理在他这里就不能被信任。所以要做 MCP 网关的监控。调用一发生，操作日志进日志库。ELK、Loki 或 CloudWatch 都可以。他举的查法包括：过去十分钟里所有的 401，以及令牌刷新失败时 OAuth 做了什么。401 是未授权的 HTTP 状态。

实时的追踪和指标进 OpenTelemetry。这个开源组件收集后再送到后端。追踪进 Tempo，同样是开源的：这次请求里哪个工具慢，调用来自代理还是 IDE，失败调用的具体错误。指标进 Prometheus：某个工具的 P95 延迟，以及认证拒绝有没有在某一时段飙高。P95 指 95% 的请求不慢于该时间。追踪和指标汇合之后，他说会存进用于可视化的 graph。字幕没有把这个 graph 说成某一个产品名。中间他有一次改口，随后把 Tempo 和 Prometheus 的分工补完。

401、P95 和认证拒绝是他举例的查询。ELK、Loki、CloudWatch 是可选项，节目没有说他们最终用了哪一个。

只读执行，写入等人批准

LangGraph 在他这里是带循环、分支和状态的图，用来做复杂的多智能体流程。查询进来，先解释问题要什么回答，再生成计划。分类节点判断这是读、修改、删除，还是敏感操作，并据此调整结构。计划本身又是一张子图，主要操作在这里。取证会去叫 MCP 网关，完成认证，用正确的工具调 MCP 服务，拿到数据，形成证据。发现经过校验，再查策略。只读就执行，并把记录写入审计日志。写入和敏感操作进入他称为 HITL 的人工批准。HITL 指人在回路里。批准才执行。拒绝也写入审计日志。

记忆是把工作流状态存下来、以后恢复，让每次运行可恢复。一次查询生成一个线程。第一个问题产生 run ID。深入的问题走到 LangGraph 的某个节点，并写下检查点。同一线程上的追问产生新的 run ID，再在对应节点存检查点。本地用 SQLite。生产若在 GCP，他用 Cloud Spanner。Azure 和 AWS 用各自的库，产品名没有点。演示从空的 SQLite 开始。提交查询后出现一条记录：线程 ID、问题、执行时间。后续查询能看这个线程上有多少消息、调用了哪些工具、线程 ID 和 run ID、MCP 上的工具名，以及图上依次走过哪些节点。

追踪评估是代理层的，和他前面的网关监控分开。要存的是提交了什么查询、回答是什么、用了哪个模型、token 成本、烧掉多少 token、评估标准、回答质量。从第一天就存。他设想一千个以上的代理，每个代理有自己的追踪评估项目和表。若是一百个代理，就是一百个项目。六个月后有人问表现、回答、质量和 token，可以把这些表汇成给高管的仪表板，用来看这么多代理的投资回报。

演示里列出六张表。他先打开任务追踪：请求 ID、会话 ID、代理名、问题、输出、是否完成、耗时、所用模型。质量表是每次运行八项检查，一行一项。他点到成功、延迟、成本、工具准确性和安全，其余没有逐项念。评估分数是一行记分板，各质量维度合成零到一的分数。质量指标是对单次运行的展开，把回答质量、安全、延迟、成本和工具统计嵌在一行里。工具调用记录哪个 MCP 工具跑了、多久、成功与否。轨迹是按顺序的步骤：每一次大模型调用和图的状态，例如计划和总结。

零到一分和八项检查是这套表的设计，节目没有给出真实流量上的分数分布。一百个和一千个代理是他用来说明表会裂开的设想。演示本身没有算出一个回报数字。

输入当下打掉密钥，上下文先裁再送

上传的文档里可能有敏感内容，打字时可能带上 API 密钥。框架给数据类型和严重程度。严重程度高于大约九成，就立刻拦截并打码。密钥不进大模型，也不进记忆库、追踪评估表和链路系统。挡住的时点是摄入的一刻，也就是打出来的时候。

上下文优化是他最看重的一块。查询和附带的大量文件，在进模型前先整形、裁剪。按 token 上限挑选载荷，重排哪些信息最相关，去掉重复，再压缩。Artifactory 那一问，优化前大约 24000 token，打开优化器后同一问大约 2400。他算成近九成的节省。Slack 机器人上他再问一次：列出 Artifactory 各仓库里的全部 Docker 镜像。优化前再次大约 24000。打开之后大约 1500。他又说近九成。多数情况他给出的节省是 70% 到 78%。若有几千个代理、每天大量查询，他让听众自己去乘这组比例。

收束时他要求建的是企业框架，代理只是其中一块。框架要一起上，免得事后才发现门禁该一开始就在。每一次工具调用，无论来自本地还是代理，都经过集中的 MCP 网关，认证之后才到 MCP 服务。服务决定用哪个工具执行。工具执行要有监控和完整审计。高风险动作保持人在回路里。可观测性和审计留在位上。上下文优化用来为代理的成本作辩护。结尾他提到自己在亚马逊发了一本 MCP 的书，Kindle 版免费，纸质版也有。

24000、2400、1500 和两处近九成，来自他当场刷新的演示。70% 到 78% 是他所说的多数情况，字幕没有给出样本量。九成严重度阈值，他说的是大约。演示用的是本地查询和 Slack 机器人。可以读成：门户把记忆、追踪、优化和脱敏生成进同一个仓库，是为了不让每个开发者自己记得住这四块。字幕在致谢处结束，没有半句截断。