做Agent开发的同学，大概率都有过这种体验：模型选好了，Prompt调通了，框架也跑起来了，结果一到接真实业务系统就卡壳——订单系统一个接口返回格式，CRM一个是XML，老系统得走SSH脚本，新服务只给gRPC。去年年初我带团队做客服Agent时，就栽在这上面，原计划两周跑通Demo，结果四周都耗在工具对接上，每天干的全是写胶水代码、对齐字段、处理超时重试。那段时间我彻底想明白一件事：AI Agent缺的不是智商，是触手。今天想聊的Agent-Reach，就是为解决这个问题写的一个开源接入层项目，专门把Agent与外部世界的“触达”问题统一收口。

如果你正在做AI Agent开发、Agent框架与编排、或者刚入门想搞懂Agent到底怎么落地，这篇文章里的架构思路、核心代码、踩坑记录都值得参考。我不会只讲概念，会把工具注册、记忆管理、安全闸门、性能调优这些实操细节全部摊开来讲。

1. Agent-Reach为什么而生：从一次崩溃的Agent项目聊起

1.1 失败项目里的四个“黑洞”

先说那个客服Agent项目。业务方要求Agent能查订单、改地址、退换货、发优惠券，听起来都是现成接口，接一下就行。可真接起来，四个问题直接把我打蒙。

第一是协议混乱。订单接口走HTTP返回JSON，老CRM系统只给XML，库存系统要打一个内部RPC，物流系统是个只有文档的SOAP服务。模型的工具调用定义只能描述“调用什么、传什么参数”，但参数怎么校验、响应怎么解析、错误怎么归类，标准工具框架完全不管，全得自己写。

第二是工具膨胀。业务方今天加一个“查询绿通订单”，明天加一个“按手机尾号过滤”。我不得不维护一百多个工具函数，命名、参数、错误码全凭各人风格，模型经常把相似工具搞混，明明该调“查询订单”却调了“查询订单详情V2”。

第三是上下文失控。Agent多轮对话里，每调一次工具，返回结果都往上下文里塞。查几单之后，上下文里全是重复字段，Token预算直接被撑爆，模型开始“忘记”用户最初问的是什么。

第四是权限失控。退换货、发优惠券这类写操作，我们最初也做成普通工具，结果测试时Agent在用户还没确认的情况下就发了一张五折券。虽然没有真实损失，但这件事提醒我：工具连接层如果没有安全闸门，生产环境早晚出大事故。

那个项目最后延期了一个半月，靠堆人力勉强上线，但代码已经烂到没人敢动。回头复盘时我确定了一件事：Agent系统的复杂度和外部系统数量成正比，而且是指数级。想靠在每个Agent框架里加插件来解决问题，根本没有尽头，必须有一层专门处理“触达”。

1.2 Agent-Reach是什么，不是什么

Agent-Reach的定位是一套开源的Agent触达层运行时。它不是一个像LangChain或Dify那样的完整Agent框架，不会帮你写Prompt、做多智能体编排、设计工作流。它的作用在更底层：把模型与外部世界（HTTP服务、数据库、文件系统、消息队列、命令行等等）之间的连接、记忆、安全、可观测性，统一收口成标准能力。

打个比方。传统微服务架构里，客户端不直接连数据库，而是经过API网关统一鉴权、限流、路由。Agent-Reach做的事情，就类似给Agent加了一个“能力网关”。模型只需要声明想要调用哪个能力、传什么参数，剩下的参数提取、连接获取、协议转换、超时重试、权限校验、结果归一化，全部由Agent-Reach完成。

这里特别要区分它和普通API网关：API网关对接的是“确定性的客户端”，请求结构从一开始就是固定的；Agent-Reach对接的是“不确定的大模型”，它压根不会严格按你的工具描述传参，你要防的是漏参、错参、幻觉参数，还要把工具错误转成模型能看懂的提示信息，引导它下一步修正。这不是单纯转发，而是有语义理解的适配层。

1.3 为什么LangChain、Dify、CrewAI本身解决不了

市面上主流Agent框架确实都支持工具调用，比如LangChain的Tool、Dify的工具节点、CrewAI的Tools机制。但它们都有一个共同问题：工具接入逻辑和框架本身深度耦合。你在LangChain里写好的工具，搬到Dify就得重写；CrewAI里的RAG工具，没法直接在别的框架里复用。对开发效率来说，这是巨大的隐性成本。

另一个问题是多数Agent框架默认站在“单次会话”角度设计。它们会帮你把工具描述塞给模型，执行完工具把结果拼回去，但很少认真处理三个跨会话问题：长期记忆怎么沉淀、工具权限怎么分级、敏感操作怎么审批。你可以自己在框架里加，但每个框架的扩展点都不一样，团队里换个人就不会用了。

我自己也经历过从LangChain切到自研编排的过程，最大的感受是：与其把一个框架越用越重，不如把最通用的“触达层”抽出来独立维护，上层不管用LangChain、Dify、CrewAI还是自己写的调度器，都通过Agent-Reach接外部系统。架构清晰，团队也更愿意遵守。

2. Agent-Reach架构拆解：连接、记忆、安全三个平面

2.1 整体分层

Agent-Reach的架构我拆成三个平面，加上一个运行时核心。三平面分别是连接平面（Connect Plane）、记忆平面（Memory Plane）、安全平面（Guard Plane）。运行时的核心是一个调度协程，它不关心你的业务逻辑，只管一件事：把Agent的意图变成外部调用，再把结果变成Agent能理解的消息。

设计成平面而不是层的理由是：三个关注点可以独立扩展。比如你只接一个内部系统，连接平面变厚；你面对敏感行业，安全平面就必须开足马力。互相之间通过事件总线通信，内存态和持久态分开存储，重启Agent进程不会把关键审计数据丢掉。

2.2 连接平面：统一工具描述协议

连接平面最核心的部分是工具描述协议。Agent-Reach要求每个工具必须用一份标准的JSON Schema描述自己的能力，包括名称、用途说明、入参字段、出参结构、错误码、幂等性标记。

选JSON Schema而不是直接用代码或纯文本Prompt，是三个原因。第一，模型对结构化描述的理解远比自由文本稳定，字段描述、类型、枚举值都可以写进Schema，模型提取参数时不容易发散。第二，Schema可以做强校验，模型漏传必填参数时，工具不会被调用，而是直接返回一个“参数缺失”的明确错误。第三，Schema是语言无关的，Python、Java、Node都能生成和解析，工具可以跨语言共享。

每个工具有且只有一个工具的“能力ID”，比如order.query、refund.apply。模型只认ID和参数，不直接接触任何URL、命令或数据库连接串。这样外部系统地址变动也不会波及模型侧，换环境时只需重新注册连接信息。

2.3 记忆平面：从会话上下文到长期知识

Agent-Reach把记忆分成三个层级：滚动窗口、会话摘要、长期向量。滚动窗口保存最近几轮对话原文，保证模型能精确引用用户原话；会话摘要在窗口滚动出界时由摘要模型生成，保留“用户问过什么、我答过什么、结果如何”；长期向量则归一化后存入向量数据库，每轮沉淀出的重点结论和用户偏好都会单独切块向量化。

三层的核心价值在于：不是所有信息都适合直接塞给模型。原文保真但占Token，摘要省Token但有信息损失，向量检索需要额外一次查询。把三层分开，运行时可以根据当前对话的需要决定从哪层取记忆。启动新会话时，优先做向量召回，把最相关的过去结论放进上下文，而不是把整个历史倒进去。

2.4 安全平面：权限、拦截、审计

安全平面可以说是Agent-Reach和“玩具Agent框架”拉开差距的地方。它默认三种策略：放行、参数校验后放行、需要人工确认。比如查询订单，校验用户身份后直接放行；修改收货地址，参数校验合法后放行；退换货、发券、转账，一律进入人工确认队列，Agent会暂停执行并把一个确认卡片推给用户，用户点击允许，工具才真正执行。

全局还有一个动态策略引擎，可以按用户角色、工具类别、时间窗口等维度下发策略。所有工具调用的尝试，无论成功失败，都会落审计日志。这个设计与可观测性打通，后面细说。

3. 核心代码实战：一个工具从注册到被Agent调用的完整链路

3.1 工具描述：先写Schema

纸上谈兵没用，直接看代码。假设我们要接入一个订单查询服务，先在Agent-Reach里定义一个工具。

下面是一份精简的工具Schema。我刻意写得很详细，因为模型提取参数的效果，和描述质量强相关。

{ "tool_id": "order.query", "name": "查询订单", "description": "根据订单编号查询订单状态、金额、物流信息。仅支持查询当前用户自己的订单。如果用户不是订单所属人，必须拒绝查询。", "input_schema": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单编号，通常是字母O开头加12位数字，例如O202404260001", "pattern": "^O\\d{12}$" } }, "required": ["order_id"], "additionalProperties": false }, "output_schema": { "type": "object", "properties": { "order_status": { "type": "string", "enum": ["pending", "paid", "shipped", "completed", "cancelled"] }, "total_amount": { "type": "number" }, "logistics": { "type": "string", "description": "物流公司及单号，未发货时为空字符串" } }, "required": ["order_status", "total_amount"] }, "idempotent": true, "timeout_ms": 3000, "auth_required": true }

这段描述里，pattern给出了订单号的精确格式，description里还写了“仅支持查询当前用户自己的订单”的边界。别小看这些描述，它会直接影响模型在多轮对话中的判断。模型读到边界条件后会自己先判断：如果用户问的是别人的订单，它会在工具调用前主动拒绝，而不是傻乎乎地发起查询。这比在代码里硬校验用户身份更符合Agent的自然行为，两层校验互相兜底。

3.2 工具注册与调用入口

工具实现本身是一个普通Python函数，但通过注册器给它补上元信息。Agent-Reach把“函数逻辑”和“协议元信息”解耦，函数只关心业务，协议相关的事全部交给装饰器。

下面是一个实际注册代码的简化版。

# agent_reach/connect/registry.py from agent_reach.schema import validate_input, normalize_output class ToolRegistry: def __init__(self): self._tools = {} self._executors = {} def register(self, tool_schema: dict): """注册函数并绑定 schema""" def decorator(func): tool_id = tool_schema["tool_id"] if tool_id in self._tools: raise ValueError(f"duplicate tool_id: {tool_id}") self._tools[tool_id] = tool_schema self._executors[tool_id] = func return func return decorator async def execute(self, tool_id: str, arguments: dict, context: dict): schema = self._tools.get(tool_id) if schema is None: raise ToolNotFoundError(tool_id) # 1. 参数校验，缺参数直接报错，不让业务函数拿到坏数据 validated = validate_input(schema, arguments) # 2. 解析并注入身份上下文 kwargs = {**validated, "__context__": context} # 3. 超时控制 result = await asyncio.wait_for( self._executors[tool_id](**kwargs), timeout=schema.get("timeout_ms", 10000) ) # 4. 输出归一化 return normalize_output(schema, result)

这里的关键设计是execute方法内部做了参数校验、超时控制、身份注入。业务函数不需要关心请求来自谁，也不需要在每个函数里重复写超时逻辑。我在实际项目里见过无数工具函数，开头三行全是校验参数、查库里有没有这个人、判断有没有权限，重复代码滚雪球一样膨胀。放Agent-Reach统一处理以后，每个工具函数平均只剩业务核心逻辑，代码量能砍掉一大半。

工具的具体使用示例：

# tools/order_tools.py from agent_reach.connect import registry @registry.register({ "tool_id": "order.query", "name": "查询订单", # ... 完整的 schema，见上方 JSON }) async def query_order(order_id: str, __context__: dict): user = __context__["user"] order = await order_service.get_order(order_id) if order.owner_id != user.id: raise PermissionDeniedError("只能查询自己的订单") return { "order_status": order.status.value, "total_amount": order.amount, "logistics": order.logistics or "" }

3.3 模型交互循环

工具注册好之后，Agent-Reach的运行时就开始跑模型交互循环。逻辑很简单：把用户问题发给模型，模型返回两种结果——要么是最终回复，要么是工具调用请求。如果是工具调用请求，路由执行工具，把工具结果作为新的消息放回上下文，再发给模型，不断循环直到模型给出最终回复。

# agent_reach/runtime/loop.py async def run_agent_reach(session_ctx, user_message: str): agent = session_ctx.agent history = await session_ctx.memory.get_recent(agent) messages = build_messages(history, user_message) for step in range(agent.max_steps): # 最多 10 步，防止无限循环 resp = await agent.llm.chat(messages) if not resp.tool_calls: await session_ctx.memory.append(agent, user_message, resp.content) return resp.content for call in resp.tool_calls: try: tool_result = await registry.execute( call.tool_id, call.arguments, context=session_ctx.context ) except Exception as e: tool_result = {"error": str(e), "retryable": is_retryable(e)} messages.append(ToolResultMessage(call, tool_result))

这个循环有三点值得展开。

无限循环是Agent最容易踩的坑。模型如果一直认为需要调用工具，就会一直调，很多内部测试里一个查询能被调用七八次。所以max_steps必须有，我的经验是线上环境设5到10步，超过就强制终止并回复用户“我需要更多信息或权限”。

工具错误必须转成模型能读懂的格式。如果你直接抛异常，模型往往只会看到一行堆栈，完全不知道该怎么修正。你应该把错误整理成结构化消息，比如“参数order_id格式错误：当前值ABC，期望以O开头的12位数字”，模型看到这个一般会自己修正工具调用参数。

retryable标记很关键。网络超时、服务不可用这类错误，模型应该换一种方式重试或告知用户稍后再试；参数错误、权限拒绝这类错误，模型应该调整参数，而不是傻傻地重试同一把调用。

3.4 错误归一化和超时策略

工具调用的失败方式五花八门：HTTP 500、连接超时、数据库锁冲突、业务系统返回“订单不存在但没报错”。Agent-Reach统一把错误归一成三类：参数校验错误、工具执行错误、外部依赖错误。

超时策略也特别提一下。Agent的响应速度直接影响用户体验，如果你接了一个慢接口，3秒超时，模型可能等2次就超过整个会话的容忍极限了。我的做法是连接平面默认超时3000毫秒，重试退避采用指数策略，第一次等200毫秒、第二次等500毫秒、第三次直接放弃。重试只对外部依赖错误生效，参数错误和业务错误绝不重试，避免给下游系统造成重复数据。

4. 记忆系统的落地：短期窗口、长期向量与写入时序

4.1 短期记忆的Token预算

很多Agent项目把历史对话直接拼进上下文，这是最简单也最粗暴的方式，表面上够用，但会话一长，Token费用和模型延迟都会线性上涨。Agent-Reach的短期记忆层做了一件事：按Token预算裁剪，而不是按消息条数裁剪。

每轮对话结束后，运行时为当前会话维护一个消息列表，并为每条消息预估Token数量。系统设置一个单次会话的Token预算，比如5000，当超出预算时，从最旧的不可裁剪消息开始淘汰，优先淘汰工具返回结果中重复度高的字段，最后才淘汰用户问题和模型回答。

实际效果非常明显：一个原本需要12000 Token的多轮会话，启用裁剪后稳定保持在5000以内，模型响应速度提升了将近一半，用户侧几乎感受不到历史信息缺失。

4.2 长期记忆：不能只靠向量数据库

长期记忆我见过很多同学一上来就接Qdrant或Pinecone，把每轮对话切块、向量化、存起来，然后检索时取Top K。单靠向量检索其实不够，主要问题有两个。

第一，向量召回的结果经常是“相关但碎片化”，比如用户上周问过“你们发货用什么快递”，这周问“我之前那单到哪了”，向量召回可能找到上周那句话，却丢失了订单号这个关键实体。第二，向量库对时间线不敏感，它会把三个月前的对话和昨天的新消息放在同一个相似度空间里，容易把过时信息当成当前状态来用。

Agent-Reach的做法是长期记忆双通道：既存向量索引，也存摘要状态。每轮会话结束时，用一个专门的摘要步骤生成三条结构化记录——主题、关键实体、结论结论。结论会覆盖同一主题下的旧结论，相当于给Agent维护了一个“可更新的状态库”。查询时先看结论，再看向量细节。

# agent_reach/memory/timeline.py async def summarize_and_store(memory_store, session_id: str, messages: list): summary = await summary_model.generate(messages) entities = await extract_entities(messages) # 订单号、日期、商品名、用户偏好 await memory_store.save_vectors(session_id, chunks=messages, entities=entities) await memory_store.upsert_summary( topic=summary.topic, entities=entities, conclusion=summary.conclusion, session_id=session_id )

比如用户上次问过“24号买的键盘什么时候发”，摘要结论里会记录“订单O202404240001，键盘，待发货，计划25号发出”。这次用户问“我那个键盘到哪了”，检索时结论通道直接把订单状态推到最前面，向量通道再补细节，模型给出的回答就既准确又连贯。

4.3 写入时序：先答后写还是先写后答

记忆写入时机是个容易被忽视但影响很大的问题。假设Agent每轮对话结束时同步做摘要和向量化，那用户会明显感觉最后一条回复很慢，因为摘要模型调用可能又要多花800毫秒到2秒。

我的经验是异步追加加关键节点固化。用户消息和模型回复在对话过程中先同步写入短期窗口，这条路径毫秒级完成。会话结束、或用户离开、或时长超过阈值时，才启动异步任务把短期窗口升华到摘要和向量库。

但有一条不能延迟：用户明确表达的重要指令，比如“以后我所有订单都优先发顺丰”，必须在当轮对话中就固化成概要状态，而不是等会话结束后再做。步骤上可以设定一个“重要信息检测”环节，命中规则就同步写入长期目标，其余内容统一异步。

4.4 记忆污染与版本控制

同步摘要的方案还有一个隐患：模型偶尔会总结错，或者用户后来自己纠正了之前的信息，旧记忆如果没有正确失效，会把整个会话带偏。Agent-Reach后来给记忆加上了版本标记。每次摘要写入时带上时间戳和来源会话ID，更新时不是覆盖旧记录，而是标记旧版本“已过期”，保留一个历史版本列表。这样即使记忆被污染，也能顺着版本往回找，知道是哪一轮会话改坏了信息，重新修正即可。

我在生产环境还遇到过一种更隐蔽的问题：调试模式下的Agent调用也会写入长期记忆。开发同学调API时，把一些测试数据当成真实信息存进了向量库，导致线上会话检索到“用户家庭地址是测试地址”。后来我在存储层加了环境和会话类型标签，测试环境的记忆永远不会进入生产检索空间。这算是记忆系统里的一个冷门但重要的细节。

5. 生产环境的安全闸门与可观测性设计

5.1 工具白名单与参数校验

Agent-Reach默认所有工具都是“禁用”状态，只有显式加入白名单才能被运行时调度。白名单按工具分组配置，比如“查询类工具”“订单处理类工具”“营销类工具”。你在接入一个工具时，只需要把Schema里的did字段配置进白名单，然后由安全平面决定该组工具有哪些额外限制。

参数校验放在调用链路的第一道关口，不进业务代码。校验规则直接复用JSON Schema的pattern、minLength、enum等定义，运行时统一校验。如果模型传了不在Schema内的字段，会被additionalProperties: false直接拒绝。这样做有一个好处：业务系统根本不会接收到来自Agent的畸形数据，下游系统不会因为Agent的幻觉参数而出现脏数据。

5.2 人工确认机制与超时处理

退换货、退款、发券、删除数据这类高危操作，Agent-Reach默认走人机确认通道。模型生成工具调用请求后，运行时不会马上执行，而是先给用户返回一个等待确认的消息，内容包括操作摘要、风险提示、确认按钮。用户确认之后，才真正执行工具。

这个机制一开始遇到一个体验问题：用户点击确认后，Agent往往是重新发起一轮完整的模型调用，把前面的意图又跑一遍，既慢又可能改变主意。后来我改成“确认令牌”模式，用户确认时生成一个有效期60秒的令牌，执行工具直接使用令牌，不用再问模型。交互快很多，安全上也没有打折扣，因为令牌和工具调用参数、用户身份都是绑定的。

这里有个必须注意的细节：超过有效期没有确认的操作要被系统自动取消，而不是无限等待。取消时还要通知Agent，让它知道这次工具调用没有发生，避免它继续“等结果”。

5.3 链路追踪与Token计量

Agent的一次完整会话可能涉及用户消息、多轮模型调用、多次工具调用、记忆读写，没有统一链路追踪，出问题时根本说不清是哪一环坏了。Agent-Reach在每次会话开始时生成一个trace_id，所有模型请求、工具调用的日志都会带上这个ID。排查问题时，只需要按trace_id搜一次，就能看到整条链路的完整时间线。

另外我强烈建议把Token消耗和工具调用都做成可查询的指标面板。模型成本不低，尤其是工具调用频繁的场景，每轮都要带上工具描述和返回结果，Token消耗可能远超你想象。给每个会话、每个用户、每个工具分别统计调用次数和Token成本，后续做定价、容量规划、性能优化才有依据。

表格是我自己常用的一套监控指标：

5.4 审计日志设计

审计日志和安全监控是两回事。监控关心“现在有没有出错”，审计关心“之前发生了什么、谁该负责”。Agent-Reach的审计日志最少要求记录五个要素：时间、会话trace_id、用户身份、调用工具ID、模型输出的原始tool_call原文。此外还要记录工具执行前后的数据变化摘要，比如“订单O202404240001状态由pending变为completed”。

审计日志的写入不能依赖Agent进程，必须独立落盘。我见过系统把审计日志存在应用日志文件里，进程重启或磁盘满了，审计数据直接丢，这是绝对不能接受的。生产环境建议把审计数据推送到独立存储或日志系统，并设置保留周期。合规角度说，涉及资金、退换货、个人信息修改的操作，至少要保留一年以上。

6. 接入效果实测与调优记录

6.1 两个真实接入案例

第一个案例是电商客服Agent。接入Agent-Reach之后，我们把查询订单、查询物流、修改地址、申请退货、领取优惠券5个工具注册进去，高危操作全部走人工确认。上线后的实测数据：用户咨询常见问题的平均应答时间从原来的人工转接58秒降到8秒，工具调用成功率96%，人工确认驳回率只有3.7%。更关键的是，新接入一个业务系统的工具，从写接口文档到注册完成，只花了一个多小时，不用再动模型层任何代码。

第二个案例是企业内部BI问答Agent。这个场景工具数量不多，但查询模式复杂，有的查询要跨两个数仓、四个API。Agent-Reach的连接平面支持把多个API编排成一个组合工具，模型只需要调用一次，内部按配置串行或并行执行。原先用LangChain实现时每次改数据源都要动链路代码，接入Agent-Reach后只改一个Schema和适配器，维护成本直线下降。

6.2 性能瓶颈与调优

跑了一段时间之后，我从监控指标里发现三个瓶颈。

第一个是工具描述本身占用Token太多。一个复杂的顺序工具，Schema有五六百行，每轮模型调用都要带上去，Token成本很高。优化方案是给工具描述做分级裁剪，常用工具全量描述，冷门工具只留一句话摘要，模型真需要时再展开。上下文Token用量降了四成。

第二个是高频工具的执行路径里重复做了JSON序列化。工具返回的字典要先序列化成JSON，模型结果再解析回字典，一来一回开销不小。优化后直接在工具层返回带校验的原生对象，只在进出运行时边界时做序列化，整体延迟下降约10%。

第三个是连接池的并发数。早期每个工具都新建一条数据库连接，压力一大就出现连接超时。后来改成按工具分组的连接池，最小连接数5、最大30，空闲超过90秒回收，数据库连接风暴再也没有出现过。

6.3 高频踩坑清单

接入过程中整理了一份高频坑清单，基本覆盖了Agent项目最常见的翻车点。

其中幂等设计最值得多说一句。Agent天然有重试行为，一旦接口响应慢，模型会重复发同样的调用请求。如果后端接口没有幂等，发券就会发两次。Agent-Reach的工具Schema里专门有idempotent字段，标记为true的工具会由运行时自动附加一个幂等键，同一幂等键的写操作在30分钟内只执行一次，这是我看过很多项目都忽略掉的关键细节。

6.4 后续扩展方向

Agent-Reach目前的版本已经把连接、记忆、安全三件套做扎实了，再往里走有三个方向。一是多Agent协作，不同Agent之间通过A2A协议交换能力，已经预留了a2a端点。这个方向很有意思，但我的经验是先把单Agent的工具调用做稳定，再上多Agent，否则问题定位会非常痛苦。二是沙箱执行，让不可信工具代码跑在隔离沙箱里，防止内部Agent被恶意输入攻击。三是支持更细粒度的技能包，Agent-Reach计划把一组工具、一组提示词、一组校验规则打包成一个技能，像插件一样按需安装，这样不同团队可以独立发布自己的Agent技能，互不干扰。

现在回头看那个上线后没人敢动的客服Agent，最大的变化不是框架换了，而是触达外部系统的逻辑终于有地方安放了。如果你也在做Agent开发，我的建议就是先别急着换模型、换框架，先看看自己和外部系统之间的连接层是不是够干净。把连接、记忆、安全这三件事统一收口，Agent才能真正从Demo变成生产工具。