Agent SDK

原文 ↗ Hacker News 讨论 ↗

快速激增的“agent SDK”（如 Cursor 的方案）常被拿来与 JavaScript 框架的频繁更迭相比，许多工程师怀疑越来越复杂的 agent 工作流是否真的胜过精心编写的 prompt 和更简单的工具。评论者权衡专有 harness（如 Claude Code、Cursor 和 OpenAI 的方案）与开源或自定义 harness 之间的取舍：前者通常针对自家模型深度优化，并通过订阅补贴，后者则承诺更高灵活性，但可能缺乏深度集成和稳定的经济模式。抛开品牌和缩写，核心矛盾仍是供应商锁定、缺乏清晰的基准或标准，以及复杂的多 agent 架构究竟能否带来真正的生产力提升，还是只是一场生产力表演。

生态系统、标准与供应商锁定

  • 一些评论希望有一个通用标准（例如 OpenResponses），这样应用就不会绑定到特定供应商（OpenAI、Anthropic、Cursor 等）。
  • 也有人指出我们正处于“前标准”阶段：由于没人知道“正确”的设计是什么，所以会出现很多并行尝试。

Agent SDK、Harness 与抽象层级

  • 有人认为“agent SDK”可以很简单：PROMPT.md + runtime + tools；像 LangChain 这样的复杂框架让人感觉过度设计。
  • 反方观点：runtime 提供了所需的控制——不同的工具、模型、权限、护栏、配额，以及跨工作流的可审计性，尤其适合企业。
  • 有几个人表示，他们使用 Temporal、gRPC、k8s，或 Google 的 ADK 作为编排骨干，而不是重量级 agent 框架。

怀疑：生产力表演与频繁变动

  • 很多人认为无休止的“agent”工作流只是炒作，缺乏实证证明它们比优秀的单次 prompt 更好。
  • 有人将其与 JS 框架更迭、OOP/UML 图表热，以及没完没了地调整开发环境（例如 neovim 配置）相提并论。
  • 也有人批评多 agent 的“软件工厂”会生成大量未经审查的 PR，警告这会降低工程标准并增加风险。

开源 vs 专有 Harness

  • 相当一部分人仍使用专有 harness（尤其是 Claude Code 和 Cursor），原因包括：
    • 与前沿模型深度集成，并有订阅价格补贴。
    • 认为模型在其“原生” harness 中表现更好。
    • 熟悉的 UX、较低的切换成本压力，以及觉得开源 harness 没有什么突出的功能。
  • 另一些人则倡导开源 harness（Pi、OpenCode、自定义方案等），强调：
    • 可在不同模型/提供商之间移植。
    • 能在订阅和 API 之间路由。
    • 没有真正的锁定，因为 harness 彼此可以调用对方的 CLI。
  • 关于 Anthropic 的条款、计费，以及第三方 harness 是消耗 Claude 订阅还是单独的 API credit，存在困惑和分歧；文档和实际行为被描述为模糊不清，但最近有所更新。

Cursor、“Agent SDK” 与替代方案

  • 有人觉得 Cursor 在追逐 agentic 工作流后，UX 反而变差了，更喜欢它早期更简单的“tabs + cmd-K”模式。
  • 也有人喜欢 Cursor 的 agentic 云端/部署叙事，并将“agents”视为可以托管和变现的工作负载。
  • 对比中提到了竞争工具（Anthropic Agent SDK、OpenAI Agents、Vercel AI/Eve、Devin），但讨论认为 Cursor 的 Agent SDK 说法并没有明显独特之处。

UI/UX 与真实业务需求

  • 一位实践者表示，最难的是领域特定的聊天 UI 和审批流程；通用聊天界面和 MCP/工具链无法解决这一点，因此很多人不得不自己重建前端。
  • 讨论中还提到各种库/框架（TanStack AI、ChatGPT Apps、自定义 TUI），它们都在尝试解决 agents 之上的更丰富 UI 流程。