HN讨论 · 身份未知
以 client shim 替代 MCP 的 agent 服务集成，降低 token 开销与体验损耗
Ardent 在 beta 发布中提出，MCP 集成慢、token 开销高、对 agent 和用户体验差；因此改为为服务的官方 API 生成 client shims，让 agent 像读取普通代码库一样调用客户端。这是对当前主流 agent 工具集成方式的具体批评与替代形态，但全部信息来自创始人自述，尚无独立验证。
查看原始信号hn:49550931
目标用户
使用 agent 并需要连接 Google、Linear 等既有外部服务来完成自动化工作的用户与团队
潜在需求
需要一种比 MCP 更高效、更省 token 的服务集成方式：生成 client shim 直接调用服务主 API，让 agent 读取客户端并像调用普通代码库一样使用，减少慢交互与高开销。
发生场景
agent 需要调用团队已经在使用的 Google、Linear 等服务时，MCP 是常见集成方式；但作者观察到 MCP 慢、token 开销高，对 agent 和用户都体验差，并且与代码生成式 agent 的配合不佳。
来源证据
作者称 MCP 慢、token 开销高、对 agent 和用户体验差，因此 Ardent 不直接用 MCP，而是生成 client shims 调用服务主 API，让 agent 把客户端当作普通库使用。
which you’re already using, like Google, Linear, and so on. We support MCP servers, but in our experience, MCP is slow, token-expensive, and provides a pretty bad experience for both agents and users. [2] Instead, Ardent connectors handle auth, but instead of using MCP, we generate client shims which call the service’s primary API. This is a much better fit for Ardent’s codegen approach, because the agent can read the client and treat it like any other library. There’s a bunch of otherhttps://news.ycombinator.com/item?id=49550931
为什么值得留意
这不是又一个通用的工具循环包装，而是基于对 MCP 的具体负面观察给出差异化解法：为服务主 API 生成 client shims。若该做法在真实任务中成立，会影响 agent 工具集成层的设计选择，也说明该环节仍有明确的优化空间。
已有方案
- 基于 MCP servers 的工具集成
- Codex / Claude Cowork 等通用 agent harness
未满足部分
- MCP 集成慢、token 开销高、对 agent 和用户体验差
- MCP 让服务调用不能像普通代码库那样被读取与组合，与代码生成式 agent 配合不佳
可能延伸 · 模型推测
- 将 client-shim 生成标准化，按服务 API 文档自动产出可供 agent 读取的客户端（模型推测）
- 在组织能力目录中沉淀跨任务复用的服务集成库（模型推测）
目前未知
- 全部信息来自创始人 beta 发布自述，尚无独立用户或第三方评测
- MCP 慢/贵的具体任务类型与测量口径未披露
- 普通用户对代码生成式 agent 的接受度未知
- Ardent 的 at-cost 推理与免费 credits 的可持续性未知
继续核实
- 在多样化真实任务中，client-shim 集成相对 MCP 的 token 与速度差异是否稳定？
- 其他 agent harness 是否会跟进类似的服务集成方式？
- MCP 生态是否会改进性能与体验，或出现替代标准？
主题词
mcp performanceagent tool integrationcode generationclient shimknowledge work automationtoken efficiency