大家好，昨晚我在冲浪的时候看到了一篇论文，其中说到了关于 Agent 服务的问题引起了我的担忧，今天就给大家分享一下吧！
前言
这一年来，越来越多的开发者开始接触甚至是大量使用 Agent AI。无论是写代码的助手、自动化运维工具、企业知识库问答，还是带有工具调用的智能体应用，很多项目都不再只是“调用一个大模型接口，然后输出一段文本”这么简单，而是开始让模型去执行命令、读写宿主环境的文件、访问数据库、调用浏览器和操作云端资源等等。
一旦走到这一步，很多开发者很自然会接触到这个东西：第三方中转服务。
它通常也叫做 API 中转、代理路由、统一网关、转发服务等。
说实话，我一开始找中转的原因也很简单：就当世最强几个模型来说，官方真的贵，而且容易遇到额度、速度或可用性问题。对普通开发者来说，中转看起来像是一个很自然的选择。
国内中转，可以做到官方服务价格的一半甚至更低。一开始，我的关注点只有两个：
但当我把它放进 Agent AI 的上下文，问题就不止是成本和可用性了，还会多出第三个更重要的问题：安全性如何？
就是一个经典的不可能三角，谁也没有把握能说自己能找到最完美的答案。
最近一篇论文《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》专门研究了这一点。
它的核心观点非常值得普通开发者了解：当 AI Agent 通过第三方中转服务调用模型时，这个中转节点并不只是“网络转发器”，而是一个拥有真实安全影响力的信任边界。
在某些情况下，它甚至可以决定你的 Agent 最终执行什么命令。
这听起来确实有点吓人，但我们也不必因此过度悲观。
更准确地说，正确理解这个问题，反而能够帮助我们更加成熟地使用中转服务，而不是因为“担心风险”就彻底放弃它。
这篇文章就想用尽量直白的方式，和普通程序员聊聊：
- 第三方中转服务到底是什么
- 为什么 Agent 场景下风险会明显放大
- 中国大陆开发者为什么更容易接触这类服务
- 真正需要担心的风险是什么，不需要过度担心的又是什么
- 如果必须使用中转服务，怎样把风险降到更合理的范围
什么是第三方中转服务？
正常情况下，你的程序直接请求模型厂商，比如 OpenAI、Anthropic、Google 等。
但在现实开发中，很多人并不是这么接的，而是把请求先发给一个“中间平台”，由它再转发给真正的模型提供方。这就是中转服务。
它之所以流行，主要有几个很现实的原因：
第一，统一接口。
不同模型厂商的 API 格式不一样。中转服务经常会把它们包装成统一格式，开发者只要接一个接口，就能切换多个模型。
第二，成本和可得性。
对于国内开发者来说，这一点尤其现实。有的人是为了便于访问，有的人是为了聚合多个渠道，有的人是为了用更低门槛测试不同模型，有的人只是想先跑通项目原型。
第三，功能增强。
有些中转服务会提供模型 fallback、负载均衡、缓存、统一计费、日志、密钥管理、额度分发等能力。这些对团队开发确实很方便，用量和成本可以衡量出来。
所以，使用中转服务本身不是“错误做法”，它有非常真实的工程价值。
问题在于：很多人把它理解成了“只是帮我转发一下请求”。问题在于，中转服务并不只是“帮你转发一下请求”这么简单。
在 Agent 场景里，中转服务为什么更敏感？
如果你只是做一个普通聊天机器人，中转服务的风险虽然存在，但还相对容易理解：
它能看到你的 prompt、用户输入和模型输出。
但 Agent 不一样。
Agent 的核心是“根据回答进一步执行动作”。
这些动作可能包括：
- 执行 shell 命令
- 安装依赖
- 读取和修改代码文件
- 调用数据库
- 操作浏览器
- 使用云平台密钥进行部署或运维等等
Agent 可以做的事情太多了！
在这个场景下，调用大模型返回的内容就不再只是文本，而可能是一个工具调用指令，里面包含要执行的命令、参数、路径、目标地址等。
论文指出，当前生态里广泛存在一个问题：没有成熟的端到端机制，能证明 Agent 最后看到并执行的 tool call，一定就是上游模型原始生成的那个 tool call。
这就意味着如果中转服务愿意，它不仅可以看到你的请求和响应，还可能改写它们。
比如，上游模型原本想让 Agent 执行一个正常命令，但中转层可以把这个命令偷偷换掉，然后再返回给客户端。只要 JSON 格式还合法，Agent 可能根本察觉不到。论文把这种行为归纳为响应侧载荷注入（AC-1）。
个人观点：他们可以这么做。一旦有足够利益的驱使，他们非常非常有可能会这么做。
论文告诉了我们什么？
这篇论文《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》把风险拆得很清楚：
- 改写返回结果，让 Agent 执行错误动作
- 不改内容，只是偷偷收集敏感信息
第一种是最直观的一类风险。论文称之为 Payload Injection。也就是说，中转服务可以篡改模型返回的工具调用参数，比如把下载地址换成攻击者控制的脚本、把正常命令改成 恶意命令。
如果你的 Agent 拿着高权限运行，而你又没有做足够的审批和隔离，那么这种篡改带来的后果会非常严重。
第二种风险甚至更隐蔽，论文把它称为 Passive Secret Exfiltration。也就是中转服务什么都不改，只是静静地扫描流经它的明文数据，把 API Key、云凭证、某种私钥、数据库地址、内部 Token 等敏感信息记录下来。
我的敏感信息就是这样泄露的 😭
这类风险最容易被普通开发者低估，因为你的系统表面上“运行完全正常”，日志也不一定有异常，但秘密已经被别人看见了。
国内开发者真的非常需要理解这个问题
这个问题在全世界都存在，但国内开发者可能更容易遇到。由于某种限制，我不方便讨论这方面的原因，相信在大家心中都有自己的答案。
就像那个经典笑话一样，某个国外的开发者认为咱们中国开发者是最注重隐私的balabala 🤣
这就导致一个现象：很多开发者并不是先学会“如何安全地信任中间层”，而是先学会“怎么把接口跑通”。
从项目推进角度看，这很正常。谁做原型都想先把东西做出来。
但如果一个项目后面逐渐接入了真实代码仓库、企业数据库、生产环境云资源、内部文档、运维工具，这时候再把中转服务只当“便宜点的 API 渠道”，就太危险了。
我们要知道的是：我们把模型请求发给中转，也就把 prompt、上下文、工具定义、命令内容、文件路径、甚至密钥暴露给了它。
在 Agent 场景里，你还可能把“实际执行语义”交到了它手上。
理解这一点，并不是为了让大家拒绝一切中转，而是为了避免一种非常常见的错误心态：
“这是模型层的事，不是安全层的事。”
实际上，它已经是安全层的事了。
研究团队对 28 个付费的 API 中转站 (来源于淘宝、闲鱼、Shopify 等店铺) 和 400 个免费中转站 (来自公开社区) 进行全面评测，结果触目惊心。
- 1 个付费中转站 + 8 个免费中转站会在响应中主动注入恶意代码
- 上面这 9 个中转站中有 2 个还部署了自适应规避触发器
- 17 个中转站触碰了研究团队故意部署的 AWS 诱饵凭证
- 1 个中转站直接窃取了研究团队放在蜜罐中的资金
总结一下，论文直接覆盖的风险：
- 篡改工具调用，诱导 Agent 执行恶意命令
- 被动收集 API Key、云凭证、私钥、内部 Token 等敏感信息
在现实中，中转服务商还干过这种事（不是扯淡，互联网有记忆）：
- 模型调包与降级
- 预充值积累了资金，服务商连夜跑路
- 上游账号违规导致整体服务中断，不然你以为那么多账号哪来的？GitHub 现在都还有批量注册账号的项目，作者还是国人...
普通开发者应该怎么做？
这就是现实世界，危险无处不在。
但是如果害怕危险而畏首畏尾，那就本末倒置了，我们也别追求“绝对安全”了，风险和权限匹配就行了。
如果后果只是改坏一个测试项目、影响本地临时环境，那容忍度可以高一些。
如果后果是泄露公司代码、误删云资源、读到生产数据库、把内部文档发出去，那就应该尽量避免走不可验证的第三方中转。
永远不要把“主密钥”直接交给 Agent，无论是否使用中转，这都是基本原则。
Agent 应该拿到的是最小权限、最短时效、最可审计的凭证，而不是“能干所有事”的万能 Key。
即使真的泄露了，也要把损失限制在一个很小范围内。
为什么非要找中转？如何寻找“靠谱”中转服务商？
既然中转有这么多问题，为什么大家还要找中转？
还是那句话，中转服务解决的是真问题：
- 它让接入多个模型变简单
- 中转能做容灾和 fallback
- 它有时候确实更便宜，更容易获得，甚至它降低了 Agent 原型开发的门槛
其次，我不会在这里推荐任何中转服务商，但是根据我用过的若干服务商的经历，我想给大家一些关于如何筛选中转服务商的建议。
- 远离“超低价、全模型支持、无限量”，不要贪小便宜，中转服务不是做慈善，羊毛出在羊身上
- 没有隐私政策、安全说明、公司主体和联系方式的中转，默认按高风险看。只给一个 API 地址和充值入口、却不说明上游来源的服务，尽量别碰。
- 舍得花钱做营销（开源热门项目赞助、著名论坛硬广）、信息公开透明、服务团队响应公开快速最佳（服务商入群又不收费，进去看看又何妨）
- 能不能退款、有没有试用或者短期套餐很重要
最后
现在这个时代，公司如果给员工提供 AI 服务或者官方的订阅真的是太好了，省下一笔钱不说，你自己用个第三方的服务，出了问题还得担责。
第三方中转服务这件事，值得你从今天开始认真看待。一旦你把 Agent 接进真实工具链，它就会变成安全问题、权限问题和责任问题。
真正值得警惕的，是你根本不知道自己在信任谁。
感谢大家看到这里，如果你喜欢我分享的内容，欢迎给我三连支持，你的支持是我更新下去的动力！
下次见，Bye 👋🏻
description: 省钱、省事之外，第三方中转到底还意味着什么？聊聊普通开发者最容易忽视的中转服务风险
cover: https://de4965e.webp.li/blog-images/2026/04/8e59c526729604e199062cca5a3668a4.png
大家好，昨晚我在冲浪的时候看到了一篇论文，其中说到了关于 Agent 服务的问题引起了我的担忧，今天就给大家分享一下吧！
前言
这一年来，越来越多的开发者开始接触甚至是大量使用 Agent AI。无论是写代码的助手、自动化运维工具、企业知识库问答，还是带有工具调用的智能体应用，很多项目都不再只是“调用一个大模型接口，然后输出一段文本”这么简单，而是开始让模型去执行命令、读写宿主环境的文件、访问数据库、调用浏览器和操作云端资源等等。
一旦走到这一步，很多开发者很自然会接触到这个东西：
第三方中转服务。它通常也叫做 API 中转、代理路由、统一网关、转发服务等。
说实话，我一开始找中转的原因也很简单：就当世最强几个模型来说，官方真的贵，而且容易遇到额度、速度或可用性问题。对普通开发者来说，中转看起来像是一个很自然的选择。
国内中转，可以做到官方服务价格的一半甚至更低。一开始，我的关注点只有两个：
但当我把它放进 Agent AI 的上下文，问题就不止是成本和可用性了，还会多出第三个更重要的问题：
安全性如何？就是一个经典的不可能三角，谁也没有把握能说自己能找到最完美的答案。
最近一篇论文《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》专门研究了这一点。
它的核心观点非常值得普通开发者了解：当 AI Agent 通过第三方中转服务调用模型时，这个中转节点并不只是“网络转发器”，而是一个拥有真实安全影响力的信任边界。
在某些情况下，它甚至可以决定你的 Agent 最终执行什么命令。
这听起来确实有点吓人，但我们也不必因此过度悲观。
更准确地说，正确理解这个问题，反而能够帮助我们更加成熟地使用中转服务，而不是因为“担心风险”就彻底放弃它。
这篇文章就想用尽量直白的方式，和普通程序员聊聊：
什么是第三方中转服务？
正常情况下，你的程序直接请求模型厂商，比如
OpenAI、Anthropic、Google等。但在现实开发中，很多人并不是这么接的，而是把请求先发给一个“
中间平台”，由它再转发给真正的模型提供方。这就是中转服务。它之所以流行，主要有几个很现实的原因：
第一，统一接口。
不同模型厂商的 API 格式不一样。中转服务经常会把它们包装成统一格式，开发者只要接一个接口，就能切换多个模型。
第二，成本和可得性。
对于国内开发者来说，这一点尤其现实。有的人是为了便于访问，有的人是为了聚合多个渠道，有的人是为了用更低门槛测试不同模型，有的人只是想先跑通项目原型。
第三，功能增强。
有些中转服务会提供模型 fallback、负载均衡、缓存、统一计费、日志、密钥管理、额度分发等能力。这些对团队开发确实很方便，用量和成本可以衡量出来。
所以，使用中转服务本身不是“错误做法”，它有非常真实的工程价值。
问题在于：很多人把它理解成了“只是帮我转发一下请求”。问题在于，中转服务并不只是“帮你转发一下请求”这么简单。
在 Agent 场景里，中转服务为什么更敏感？
如果你只是做一个普通聊天机器人，中转服务的风险虽然存在，但还相对容易理解：
它能看到你的 prompt、用户输入和模型输出。
但 Agent 不一样。
Agent 的核心是“根据回答进一步执行动作”。
这些动作可能包括：
Agent 可以做的事情太多了！
在这个场景下，调用大模型返回的内容就不再只是文本，而可能是一个工具调用指令，里面包含要执行的命令、参数、路径、目标地址等。
论文指出，当前生态里广泛存在一个问题：没有成熟的端到端机制，能证明 Agent 最后看到并执行的 tool call，一定就是上游模型原始生成的那个 tool call。
这就意味着如果中转服务愿意，它不仅可以看到你的请求和响应，还可能改写它们。
比如，上游模型原本想让 Agent 执行一个正常命令，但中转层可以把这个命令偷偷换掉，然后再返回给客户端。只要 JSON 格式还合法，Agent 可能根本察觉不到。论文把这种行为归纳为响应侧载荷注入（AC-1）。
论文告诉了我们什么？
这篇论文《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》把风险拆得很清楚：
第一种是最直观的一类风险。论文称之为 Payload Injection。也就是说，中转服务可以篡改模型返回的工具调用参数，比如把下载地址换成攻击者控制的脚本、把正常命令改成
恶意命令。如果你的 Agent 拿着高权限运行，而你又没有做足够的审批和隔离，那么这种篡改带来的后果会非常严重。
第二种风险甚至更隐蔽，论文把它称为 Passive Secret Exfiltration。也就是中转服务什么都不改，只是静静地扫描流经它的明文数据，把 API Key、云凭证、某种私钥、数据库地址、内部 Token 等敏感信息记录下来。
这类风险最容易被普通开发者低估，因为你的系统表面上“运行完全正常”，日志也不一定有异常，但秘密已经被别人看见了。
国内开发者真的非常需要理解这个问题
这个问题在全世界都存在，但国内开发者可能更容易遇到。由于某种限制，我不方便讨论这方面的原因，相信在大家心中都有自己的答案。
这就导致一个现象：很多开发者并不是先学会“如何安全地信任中间层”，而是先学会“怎么把接口跑通”。
从项目推进角度看，这很正常。谁做原型都想先把东西做出来。
但如果一个项目后面逐渐接入了真实代码仓库、企业数据库、生产环境云资源、内部文档、运维工具，这时候再把中转服务只当“便宜点的 API 渠道”，就太危险了。
我们要知道的是：我们把模型请求发给中转，也就把 prompt、上下文、工具定义、命令内容、文件路径、甚至密钥暴露给了它。
在 Agent 场景里，你还可能把“实际执行语义”交到了它手上。
理解这一点，并不是为了让大家拒绝一切中转，而是为了避免一种非常常见的错误心态：
“这是模型层的事，不是安全层的事。”
实际上，它已经是安全层的事了。
研究团队对 28 个付费的 API 中转站 (来源于淘宝、闲鱼、Shopify 等店铺) 和 400 个免费中转站 (来自公开社区) 进行全面评测，结果触目惊心。
总结一下，论文直接覆盖的风险：
在现实中，中转服务商还干过这种事（不是扯淡，互联网有记忆）：
普通开发者应该怎么做？
这就是现实世界，危险无处不在。
但是如果害怕危险而畏首畏尾，那就本末倒置了，我们也别追求“绝对安全”了，风险和权限匹配就行了。
如果后果只是改坏一个测试项目、影响本地临时环境，那容忍度可以高一些。
如果后果是泄露公司代码、误删云资源、读到生产数据库、把内部文档发出去，那就应该尽量避免走不可验证的第三方中转。
永远不要把“主密钥”直接交给 Agent，无论是否使用中转，这都是基本原则。
Agent 应该拿到的是最小权限、最短时效、最可审计的凭证，而不是“能干所有事”的万能 Key。
即使真的泄露了，也要把损失限制在一个很小范围内。
为什么非要找中转？如何寻找“靠谱”中转服务商？
既然中转有这么多问题，为什么大家还要找中转？
还是那句话，中转服务解决的是真问题：
其次，我不会在这里推荐任何中转服务商，但是根据我用过的若干服务商的经历，我想给大家一些关于如何筛选中转服务商的建议。
最后
现在这个时代，公司如果给员工提供 AI 服务或者官方的订阅真的是太好了，省下一笔钱不说，你自己用个第三方的服务，出了问题还得担责。
第三方中转服务这件事，值得你从今天开始认真看待。一旦你把 Agent 接进真实工具链，它就会变成安全问题、权限问题和责任问题。
真正值得警惕的，是你根本不知道自己在信任谁。
感谢大家看到这里，如果你喜欢我分享的内容，欢迎给我三连支持，你的支持是我更新下去的动力！
下次见，Bye 👋🏻