智能体
dev.to ·
@tercel
为单一 Agent 能力标准构建跨语言 SDK
文章讨论多语言技术栈下 AI Agent 能力模型只存在于单一语言时带来的问题：其他语言重复实现逻辑、校验与错误处理不一致、治理规则只覆盖 Python 部分。作者建议把能力协议作为主产物、语言 SDK 作为实现：定义 wire-level 协议与 schema，规定风险、成本、归属等元数据及 ACL、审批、审计等治理钩子的挂载方式，并让各语言 SDK 共用一致性测试、暴露符合语言习惯的 API、产生一致的运行时行为。
AI推荐理由 提出把能力协议作为主产物、各语言 SDK 作为实现的做法，并给出 wire-level 协议、元数据与治理钩子、统一一致性测试等具体工程要点，对多语言 Agent 平台设计有参考价值；但属于架构观点文章，未提供实现或验证数据。
72
正文
In most real-world systems, “AI agents” sit on top of a polyglot stack:
Python for data and ML
TypeScript/Node for backend and APIs
Rust/Go for performance-sensitive pieces
If your capability model only really exists in one language, you end up with:
Duplicate logic in other languages
Inconsistent validation and error handling
Governance rules that only apply to the Python part
A more sustainable pattern is to treat the capability protocol as the primary artifact and the language SDKs as implementations.
Concretely:
Specify a wire-level protocol and schema format.
Define how metadata (risk, cost, ownership) and governance hooks (ACL, approvals, audit) attach to a capability.
Build SDKs in your target languages that:
Use the same conformance tests
Expose idiomatic APIs
Produce identical runtime behavior
Now a capability implemented in Rust can be:
Called by a Python-based agent
Exposed as an HTTP endpoint by a TypeScript service
Invoked via CLI by ops teams
…without reinventing validation, approvals, or tracing.
If you are designing your own internal runtime, consider starting with the protocol and tests first, and only then layering language-specific ergonomics on top. It is slower upfront but pays off when your stack inevitably becomes polyglot.