代理构建
使用 LangChain 连接，受管深度代理实现每调用者身份
Arjun Patel
@agent-builder-weekly·2026年9月14日
3 分钟阅读0 浏览
LangChain 最新的博客文章推出了 Connections，这是一种轻量级抽象，可将每调用者身份和凭证管理注入受管深度代理。实际上，这意味着自主代理现在可以代表每个终端用户执行操作，而不会牺牲安全性或可扩展性——这一直是开发生产级 AI 助手的长期难题。
Connections 的核心是一个简单的契约：Connection 对象知道如何获取、刷新并注入凭证到代理的工具调用中。框架提供了对 OAuth‑2、API 密钥乃至自定义密钥存储的内置适配器，但其设计刻意保持可插拔。社区贡献者只需实现两个方法——get_token(user_id) 和 refresh_token(refresh_token)——即可加入新提供者，受管深度代理会根据传入请求的身份令牌自动将调用路由到相应的 Connection。
下面是一个最小示例，演示如何将 Google Calendar OAuth 连接集成到受管深度代理中。该代码片段位于典型 LangChain 仓库的 connections/ 目录下，可通过现有 CI 流水线完整测试。
python
# connections/google_calendar.py
from langchain.connections import BaseConnection
from google_auth_oauthlib.flow import InstalledAppFlow
class GoogleCalendarConnection(BaseConnection):
SCOPES = ["https://www.googleapis.com/auth/calendar.readonly"]
def get_token(self, user_id: str) -> str:
# In production this would query a secure DB keyed by user_id
token = self.secret_store.get(f"gcal:{user_id}")
if token and not token.expired:
return token.access_token
return self._perform_oauth(user_id)
def _perform_oauth(self, user_id: str) -> str:
flow = InstalledAppFlow.from_client_secrets_file(
"client_secret.json", self.SCOPES
)
creds = flow.run_local_server(port=0)
self.secret_store.set(f"gcal:{user_id}", creds)
return creds.token随后，受管深度代理在其配置中声明该连接：
yaml
agent:
name: calendar_assistant
connections:
- type: google_calendar
alias: gcal_conn当用户调用 list_events 工具时，代理会通过 gcal_conn.get_token(user_id) 获取相应的令牌并将其附加到 HTTP 请求中。工具实现本身无需任何代码修改；连接层负责所有凭证的处理。
从生态系统的角度看，Connections 使安全凭证处理民主化。此前，开发者只能采用临时的令牌传递或硬编码的服务账号，这都会破坏多租户的保障。通过将每调用者身份提升为一等概念，LangChain 鼓励可复用、社区驱动的认证适配器——类似于 LLM 推理后端的活跃插件生态。
Connections 的开源特性也降低了合规团队的门槛。审计员可以审查 BaseConnection 合约，组织可以 fork 代码库以集成内部密钥管理方案（如 HashiCorp Vault），而无需修改核心代理逻辑。这种关注点分离契合了 AI 代理“基础设施即代码”的更广泛趋势，使安全、可观测性和可扩展性实现模块化。
总之，LangChain 的 Connections 将受管深度代理从单租户演示转变为真正的多用户服务，为尊重每个调用者身份的企业级 AI 助手铺平道路。社区对自定义适配器的快速采纳有望加速 AI 代理生态的成熟，使安全的每用户 AI 交互成为新基准。
图片：NoName_13 / Pixabay (https://pixabay.com/photos/oldtimer-ferrari-auto-retro-4097480/)
评论 (3)
This is a critical step for unlocking scaled, personalized AI assistants. From a RevOps perspective, the ability to securely manage per-user credentials directly impacts data integrity and attribution accuracy in user-specific workflows, which is essential for understanding customer journey touchpoints. How do you see this feature impacting the observability of individual user interactions within the agent's decision-making process?
Great question. In the code, Connections acts as a clean injection layer that passes user context into the agent's state without hardcoding secrets, which keeps your tracing pipelines clean. For observability, this means you can finally attach span tags like user_id or session_id directly to the agent's decision nodes, making it easy to slice LangSmith or OpenTelemetry traces by specific customer segments rather than looking at a black box of aggregated logic.
Exactly, the injection layer gives us a deterministic hook for tagging spans, letting us map each decision node back to a specific user_id or session_id and feed that granularity into our attribution models. With that level of observability we can surface segment‑level conversion lift and detect funnel drift before it erodes quota.
Spot on—once you wire the user_id into the Connection’s context, you can emit a custom LangSmith metric right after each tool call, e.g. `langsmith.record_metric("step_latency", elapsed, tags={"user": uid, "node": step_name})`, which gives you the per‑segment lift view you need while keeping the tracing graph tidy.
This is a solid step for enterprise-grade agents, Vikram here. The pluggable nature of these connections is key for adoption, especially since operations teams are already juggling so many secret management solutions. It'd be interesting to see how this integrates with existing enterprise credential stores and IAM policies beyond the built-in adapters.
I agree, Vikram—what's exciting is that the LangChain SDK already exposes a simple Connection interface, so teams can drop in a custom adapter for Vault, Azure Key Vault, or Okta without touching core agent logic. In fact, the recent open‑source contribution from the CloudOps guild adds a thin wrapper around AWS Secrets Manager that respects IAM roles, showing how the community can extend the built‑in adapters to fit any enterprise policy framework.
Great demo—exposing per‑caller tokens opens a cheap route to hyper‑personalized outreach, letting growth teams pull a prospect’s calendar availability in real time without a shared service account. Just watch out for token‑refresh churn; a spike in refresh calls can trip rate limits and hurt email‑deliverability pipelines if you’re chaining calendar data into drip sequences.
Totally agree—token churn is the hidden cost. In practice I’ve seen teams mitigate it by sharding the token cache per user, adding exponential backoff on refresh, and wiring LangChain’s token‑refresh hooks into a rate‑limited queue so calendar pulls stay snappy without tripping email‑deliverability limits.