LiteLLM Terraform Provider 的 litellm_agent 数据源以 IaC 方式读取 A2A Agent 配置【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM 的 Terraform Provider位于仓库terraform/provider/目录允许你用 Infrastructure as Code 的方式管理 LiteLLM Proxy 上的模型、密钥、团队、MCP Server 和 A2A Agent 等资源。litellm_agent数据源用于按 ID 读取 Proxy 上已存在的 A2AAgent-to-AgentAgent 的完整元数据包括 Agent Card、访问权限、限流与花费等字段并且出于安全考虑刻意不返回敏感字段。读完本文你将了解该数据源的完整用法、参数与导出属性、底层 Go 实现与 API 调用链以及如何与litellm_agent资源和litellm_agents列表数据源配合使用。一、背景LiteLLM Proxy 中的 A2A Agent 与数据源的定位LiteLLM Proxy 内置了 A2A Agent 管理能力管理端点集中在/v1/agents路径族下GET /v1/agents、GET /v1/agents/{agent_id}、POST、PATCH、DELETE以及make_public等其注册表实现位于 agent_registry.pyA2A 协议路由位于 a2a_endpoints.py。在 Terraform Provider 中每个受管对象通常成对出现资源litellm_agent可写支持创建/读取/更新/删除数据源litellm_agent本文主角只读用于在配置中引用一个已存在的 Agent列表数据源litellm_agents只读列出 Proxy 上所有 Agent。三者均在 provider.go 中注册。litellm_agent数据源与列表数据源共用同一个 Go 文件 data_source_agent.go其官方文档即本文对应的 agent.md列表版数据源文档见 agents.md。前提条件与 Provider 一致见 READMETerraform 0.13.xProvider 版本号与 LiteLLM 版本对齐建议按 Proxy 实际运行版本锁定例如terraform { required_providers { litellm { source BerriAI/litellm version ~ 1.99.0 # 与你 Proxy 运行的 LiteLLM 版本保持一致 } } } provider litellm { api_base var.litellm_api_base api_key var.litellm_api_key }二、基本用法按 ID 读取 Agent 并解码 Agent Card原文档给出的示例如下完整继承data litellm_agent existing { agent_id 123e4567-e89b-12d3-a456-426614174000 } output agent_card { value jsondecode(data.litellm_agent.existing.agent_card_params) }要点说明agent_id是必填参数通常是一个 UUID 格式的 Agent 唯一标识agent_card_params以JSON 对象字符串形式导出Terraform 中的string类型因此需要用jsondecode()将其还原为对象后才能访问url、skills、capabilities等字段该数据源只读取不会修改任何 Agent 状态。一个更贴近实际编排的用法示例——把读到的限流值传递给下游资源data litellm_agent existing { agent_id var.agent_id } output agent_name { value data.litellm_agent.existing.agent_name } # agent_card_params 是 JSON 字符串需要 jsondecode 后才能按对象访问 output agent_card_url { value jsondecode(data.litellm_agent.existing.agent_card_params).url } # 列表数据源可先枚举全部 agent再按 id 反查 data litellm_agents all {} output all_agent_ids { value data.litellm_agents.all.ids }三、参数Argument参考litellm_agent数据源只接受一个参数在 data_source_agent.go 中定义为Type: schema.TypeString、Required: true参数必填类型说明agent_id是string要读取的 Agent 唯一标识注意与资源不同数据源没有agent_name、agent_card_params等可写参数——它们全部是Computed由 API 返回值填充这是 Terraform 只读数据源的标准形态。四、导出属性Attribute参考原文档列出的导出属性全部继承如下并补充了 data_source_agent.go 中的 Go 类型映射便于理解类型转换与空值行为属性Terraform 类型Go 类型说明agent_namestringTypeStringAgent 名称agent_card_paramsstringTypeStringA2A Agent Card以 JSON 对象字符串导出需用jsondecode解码object_permissionstringTypeString访问控制权限JSON 对象字符串extra_headerslist(string)TypeList元素TypeString会被转发给 Agent 的入站请求头名称列表tpm_limitnumber(int)TypeInt每分钟 token 上限rpm_limitnumber(int)TypeInt每分钟请求数上限session_tpm_limitnumber(int)TypeInt会话级每分钟 token 上限session_rpm_limitnumber(int)TypeInt会话级每分钟请求数上限spendnumber(float)TypeFloat该 Agent 累计记录的花费created_atstringTypeString创建时间戳updated_atstringTypeString最后更新时间戳created_bystringTypeString创建者updated_bystringTypeString最后更新者关于空值四个限流字段和spend在 Go 侧以指针*int/*float64接收只有当 API 响应中实际返回该字段时才会写入 state若 Proxy 未返回字段为nilstate 中保持未设置状态而不是0。agent_card_params与object_permission同理仅在非nil时经json.Marshal序列化后写入。五、实现解析一次读取背后的调用链数据源的读取逻辑集中在 data_source_agent.go 的dataSourceLiteLLMAgentRead函数中流程如下构造请求从 state 取agent_id调用MakeRequest(client, GET, fmt.Sprintf(endpointAgentByID, agentID), nil)其中endpointAgentByID常量定义为/v1/agents/%s见 resource_agent.go。404 处理若响应状态码为404 Not Found直接返回agent id not found错误。这一点与资源侧行为形成对比——资源的 Read 遇到 404 时只是把 ID 置空从 state 中移除用于感知已被外部删除而数据源场景下找不到目标就是配置错误必须报错避免静默使用一个不存在的 Agent。响应解码将 JSON 响应体解码为agentAPIResponse结构体定义在 resource_agent.go 与 resource_agent.go字段与上文属性表一一对应agent_id、agent_name、agent_card_params、object_permission、extra_headers、四个限流指针字段、spend及四个审计字段。写入 stated.SetId(agentResp.AgentID)后逐项d.Setagent_card_params/object_permission两个对象字段在写入前先做json.Marshal序列化为字符串这也是为什么消费侧必须jsondecode。从源码结构看数据源与资源共用agentAPIResponse结构体和endpointAgentByID常量保证了读出来的字段和资源可管理字段在契约上保持一致而资源侧的写路径是POST /v1/agents创建、PATCH /v1/agents/{id}更新、DELETE /v1/agents/{id}删除可在 resource_agent.go 中查看完整 CRUD 实现。Proxy 服务端对应的数据模型是AgentResponse/AgentTableClientagent_registry.py 中可见spend: float、created_by: str | None等字段其spend、created_by、updated_at等语义与数据源导出属性相互印证。六、安全设计为什么拿不到 litellm_params 和 static_headers原文档的 Security Note 明确指出litellm_params和static_headers不会通过该数据源暴露因为它们可能包含 API key 或 token。这一点可以从源码中得到完整印证在资源定义中litellm_params与static_headers均标记了Sensitive: trueTerraform 会在plan/apply输出中遮蔽它们且描述里写明 Never read back from API见 resource_agent.goagentAPIResponse结构体中根本没有这两个字段——API 读取响应中就不包含它们数据源自然也导不出资源的 Read 函数也刻意不从 API 回填这两个字段保证 state 中始终是你配置的值配置值即权威值而不是服务端可能脱敏/合并后的值。因此如果你的 Terraform 配置需要引用某 Agent 的模型或密钥参数只能显式引用自己的变量而不能依赖从远端 Agent 读回来——这是该数据源有意为之的安全边界而非功能缺失。七、与 litellm_agent 资源和 litellm_agents 列表数据源的配合同一文件中的 dataSourceLiteLLMAgents 提供列表能力文档见 agents.md# 获取所有 agent data litellm_agents all {} # 仅返回 URL 当前可达或没有 URL的 agentproxy 会探测每个 agent 的 URL data litellm_agents healthy { health_check true }health_check true时Provider 会在请求 URL 上追加?health_checktrue对应 Proxy 端GET /v1/agents?health_checktrue的过滤行为列表数据源导出idsID 列表和agents每个条目含agent_id、agent_name、限流、spend与审计字段。一个常见的编排模式是先用列表数据源枚举健康 Agent再对目标 ID 用litellm_agent数据源读取包含agent_card_params和object_permission的完整对象——列表条目不含这两个 JSON 字段完整信息只有单条数据源能拿到。而当你需要创建或变更Agent 时使用资源resource litellm_agent my_agent { agent_name my-agent agent_card_params jsonencode({ protocolVersion 1.0 name Hello World Agent description Just a hello world agent url http://localhost:9999/ version 1.0.0 defaultInputModes [text] defaultOutputModes [text] capabilities { streaming true } skills [] }) tpm_limit 1000 # agent_id 由创建响应返回并写入 state可反哺给 data 块 }资源侧对agent_card_params/object_permission/litellm_params使用agentSuppressEquivalentJSON做 JSON 语义级 diff键序不同但内容相同则不触发变更细节可参考 resource_agent.go。八、测试证据数据源行为有单元测试直接验证见 data_source_agent_test.goTestDataSourceLiteLLMAgentRead起一个httptestmock server断言请求必须是GET /v1/agents/agent-123随后验证d.Id()被设为agent-123、agent_name为my-agent、agent_card_params是合法 JSON 且url字段正确、spend为1.5、tpm_limit为1000——与本文属性表逐条对应TestDataSourceLiteLLMAgentsRead验证health_check true会生成health_checktrue查询参数且ids/agents两个列表属性按响应正确填充。在terraform/provider目录下执行make test见 Makefile 与 README 的 Development 章节即可复现这些验证。此外仓库 CI 还会通过tools/endpointaudit/对 Provider 调用的每个端点与 Proxy 生成的 OpenAPI schema 做静态审计防止 Provider 与 LiteLLM API 漂移。九、小结litellm_agent数据源是 LiteLLM Terraform Provider 中读取单个 A2A Agent 的只读入口唯一参数agent_id通过GET /v1/agents/{agent_id}获取数据Agent 不存在时以明确错误终止 plan/apply导出 13 个属性其中agent_card_params与object_permission为 JSON 字符串消费侧用jsondecode解码litellm_params、static_headers因可能含密钥而故意不导出敏感字段在资源侧也以Sensitive处理与litellm_agents列表数据源支持health_check和litellm_agent资源配合可以覆盖枚举 → 详情读取 → 声明式管理的完整 IaC 工作流。相关路径索引数据源文档 agent.md、列表数据源文档 agents.md、数据源实现 data_source_agent.go、资源实现 resource_agent.go、注册入口 provider.go、Provider 说明 README、Proxy 侧 Agent 注册表 agent_registry.py。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考