写这篇东西的起因是我过去两年里看了不下二十个企业 Agent 平台的 Demo也亲手帮三家公司做过从 PoC 到生产环境的迁移。最扎心的现象是Demo 阶段人人都觉得手里握着下一代生产力一旦把 Agent 接到真实业务里Prompt 漂移、工具调用超时、上下文爆炸、成本账单说不清最后默默退回人工流程。问题不在模型不够聪明而在平台层几乎什么都没准备好。这篇文章想从工程视角聊聊企业 Agent 平台真正缺少的东西按我踩坑的顺序拆成五块拼图讲每块都有实操细节和真实教训适合正在搭平台、或者准备把 Agent 推向生产的团队参考。1. Demo 和生产之间隔着的不是一层窗户纸1.1 Demo 是表演生产是兜底Demo 的本质是给一个精心挑选的输入跑一条事先调好的路径最后展示一个预期的结果。整个流程里所有的异常分支都被剪掉了模型答错的部分被重试或者被主持人一句我们再试一次带过去。这在逻辑上没有任何问题因为 Demo 的目的就是验证这件事在理想条件下能不能成立。但生产环境完全没有这个前提。生产意味着真实用户会输入十种不同的说法表达同一个需求会遇到网络抖动、接口限流、上游系统崩溃会问 Demo 里完全没出现过的长尾问题。生产环境里代码不仅要处理正常路径更重要的是处理异常路径——模型返回格式错误怎么办、工具调用超时怎么办、上下文塞满了怎么办、用户连续三句话都在重复同一个问题怎么办。我经常说一句话Demo 验证的是模型的上限生产考验的是系统的下限。上限决定了一个功能能不能吸引眼球下限决定了它能不能活过第一个月。企业 Agent 平台真正缺少的从来不是把模型上限再抬高一截而是把系统下限托住的那一堆无聊但要命的工程能力。1.2 大多数 Pilot 项目是怎么死的根据我的观察大多数企业 Agent 项目不是被模型能力打死的而是被三件事耗死的。第一效果不可预测。上周调好的 Prompt 这周突然变差了没有人知道为什么因为没有日志、没有版本管理、没有评测集。第二成本不可控。一个 Agent 单次对话可能要调用三到五次大模型有时候还要检索、要调工具账单出来的时候财务直接懵了。第三没有人敢担责。Agent 做错了决策谁负责没有审批机制、没有操作留痕、没有回滚手段业务部门不敢把核心流程交给一个看起来能跑的东西。这三件事任何一件都足以让项目停在 Pilot 阶段。而它们有一个共同点都不是模型层的问题而是平台层的问题。所以我的判断很明确企业 Agent 平台的第一优先级不是更强的主体框架而是补齐生产级的基础设施。2. 平台缺少的第一块拼图全链路可观测性2.1 先看清成本和延迟再谈智能我在帮一家公司做迁移的时候发现他们的 Agent 日志就是一行AI 回复了什么。我问他们你知道一次完整对话调了哪几个模型吗每个模型多少 token工具调用花了几秒重试了几次他们答不上来。生产级 Agent 的可观测性第一层就是要能回答这些账单级的问题。我建议至少记录以下信息条目是否必需说明模型名与版本必需知道是哪个模型在干活Prompt 变更也依赖它做回归Prompt 与完整响应必需完整留痕事后定位问题全靠它输入/输出 token 数必需成本核算的基础按调用方拆分单次调用延迟必需拆解到模型、检索、工具等环节重试次数与原因推荐判断模型是不是在反复挣扎工具入参与返回推荐工具链路出问题时的定位关键有了这张表你才能回答老板的三个经典问题钱花在哪了为什么这么慢这个错是谁造成的我在实际落地时发现一个经验如果你用 LangChain 或 LangGraph 这类框架自带的 trace 信息务必开起来无论存到 LangSmith 还是自建 Langfuse先把链路串起来再说。如果你们是自研框架最简单的方式是给每次 Agent 运行分配一个 request_id所有环节都带这个 id 打日志用类似 OpenTelemetry 的思路做 span。别一上来就追求分布式追踪系统能先做到一次对话的所有环节可以按时间线串起来就已经超过大部分团队了。2.2 Trace 里最容易漏掉的三个字段很多人搭了日志但缺了三个关键字段导致事后排查还是抓瞎。第一个是触发源。这条 Agent 请求是用户直接在对话框发的还是某个定时任务触发的还是上游系统通过 API 调过来的没有触发源你就无法区分用户报障和系统告警是两个完全不同的处理路径。第二个是决策依据。Agent 为什么选择了这个工具而不是另一个如果你记录的是最终结果而不是决策过程那么当 Agent 选错工具时你只能看到结果错了但不知道为什么。LangGraph 这类图编排框架天然会记录节点间流转你可以把每个节点的输入输出都打出来。第三个是用户反馈信号。生产环境的 Agent 做完一件事后用户有没有确认有没有改答案有没有投诉这些信号是评测集之外最重要的效果指标。我做过一个简单的做法在对话结尾让用户点有帮助/没帮助然后把结果关联到对应的 trace 上。一个月下来哪个 Prompt 分支在拖后腿一清二楚。2.3 实操用最少代码搭一个 Agent 追踪中间层如果你是自研 Agent我给一个最小可落地的方案不用上什么重框架就在 Agent 的主循环里手动记录一个事件列表import time import uuid class AgentTracer: def __init__(self, request_id: str): self.request_id request_id self.events [] def record(self, stage: str, payload: dict): self.events.append({ ts: time.time(), stage: stage, payload: payload, }) def dump(self) - dict: return { request_id: self.request_id, events: self.events, total_tokens: self.token_usage(), } def token_usage(self) - int: return sum( e[payload].get(tokens, (0, 0))[0] e[payload].get(tokens, (0, 0))[1] for e in self.events if e[stage] model_call ) # 使用示意 tracer AgentTracer(request_idstr(uuid.uuid4())) tracer.record(model_call, {model: gpt-4o, prompt: user_query, tokens: (1024, 512)}) tracer.record(tool_call, {tool: query_stock, params: {sku: A100}, result: available})这个中间层做出来之后剩下的就是把它接入日志系统再配一个简单的查询页面。别嫌它土我亲手验证过一套三百行的追踪中间层就能解决百分之八十的这个 Agent 刚才到底干了什么的问题。3. 平台缺少的第二块拼图记忆与状态管理3.1 三种记忆不能混为一谈Demo 里的记忆通常就是直接把历史对话往上下文里塞。生产环境里这么干很快就出事故。企业 Agent 平台的记忆至少分三层千万不要混。对话级记忆指的是当前会话内用户说了什么、Agent 答了什么。这个相对简单滑动窗口裁剪即可。业务级记忆就难了它指的是跨会话的业务上下文用户上次提交的订单号是多少客户的行业是什么这个项目的审批状态走到哪一步了这些都必须在独立的业务存储里读出来而不是靠模型回忆。长期知识记忆则是企业知识库、产品文档、过往案例这类静态知识通常存在向量库里做检索增强。三层记忆的读写频率、存储介质、一致性要求完全不同混在一个 Redis 或者一个向量库里后期一定会爆炸。3.2 状态不离线生产 Agent 的硬约束做 Demo 时 Agent 无状态也无所谓反正每一轮都是从头跑。生产环境不行用户可能在对话中问一句刚才那个报价单呢也可能隔三天回来说上次那个方案我们领导批了。这时候如果 Agent 没有可靠的业务级状态管理它就只能靠上下文里还残留着——一旦会话超时被清掉、或者用户换了个终端一切归零。我在项目里见过最典型的翻车现场Agent 帮用户提交了采购申请生成了申请单号然后用户过了两小时问我这个单子到哪一步了Agent 一脸茫然因为它把申请单号放在上一轮对话上下文里而那个会话已经被回收了。所以生产级设计必须确立一条原则状态不进上下文上下文只放对当前决策有用的摘录完整状态永远落在存储层。每个业务实体订单、申请、工单都有唯一标识Agent 通过工具读写这些实体的状态而不是靠人话描述。这个原则往深了说就是让 Agent 从一个聊天模型变成一个业务系统的操作员。3.3 实操分层的状态存储怎么选型我的建议是这样一套组合对话状态用 RedisTTL 按会话生命周期设置存角色、消息摘要、关键实体 id。只存最近 N 轮历史对话归档到数据库。业务状态用传统关系库或文档库每个业务实体一张表字段里必须包括当前状态机节点负责人更新时间。Agent 的所有业务操作都走这里。知识记忆用向量库企业文档切块后做 embedding检索结果作为上下文附加上去。向量库不要存业务状态它不适合强一致性的更新。这套组合不是银弹但能覆盖我见过的大多数企业场景。有人问过我能不能全都塞进一个大上下文里我说你试试就知道上下文一涨成本线性涨、延迟也涨而且模型对中段信息的注意力会衰减到时候你会花钱买一个更笨的助手。4. 平台缺少的第三块拼图工具调用的可靠性治理4.1 工具在 Demo 里是函数在生产里是接口Demo 阶段调用一个工具就是写个函数传参、返回、完事。生产环境里每个工具背后都是一个真实系统ERP、CRM、审批流、库存服务。这意味着三件事必须解决。权限。不是每个用户都能调用所有工具。一个实习生账户不能发起百万级采购审批。工具层必须有和业务权限体系打通的鉴权而不是 Agent 拿到什么 key 就调用什么。审计。谁在什么时间基于什么理由调用了这个工具必须留痕。这既是合规要求也是事后追责的基础。稳定性。上游系统可能 5 秒才响应可能返回 502可能字段格式和文档不完全一致。你的 Agent 必须能处理这些而不是一遇到异常就抱歉我遇到问题。4.2 超时、重试、幂等工具层的三大件我在生产项目里总结了一个工具调用的最小防御集。超时是必须的。每个工具调用必须设置超时上限通常 5 到 10 秒。没有超时的 Agent 调用会被一个卡住的上游系统拖死整个并发池。重试要聪明。遇到瞬时错误503、网络超时可以重试遇到业务错误参数非法、权限不足重试是浪费。而且重试必须带间隔和次数上限我一般用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒最多三次。幂等是最高优先级。如果提交订单这个工具被重试了两次会不会生成两笔订单生产环境里这个问题是要命的。解法是幂等键——每次 Agent 工具调用都带一个唯一的请求 id服务端凭这个 id 去重。我在架构评审时看到过太多团队完全没意识到这个问题直到上线后第一天就出现重复订单才发现。4.3 实操给工具层加一道守卫中间件用一个统一的装饰器或者网关来实现工具的可靠调用不要在每个工具内部各自处理超时重试。我给一个 Python 示意import functools import time import uuid class ToolExecutionError(Exception): pass def agent_tool(max_retries3, timeout8): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): request_id kwargs.pop(_request_id, str(uuid.uuid4())) for attempt in range(max_retries): try: return func(*args, **kwargs, _request_idrequest_id) except TimeoutError: time.sleep(2 ** attempt) except ServerError as e: if e.retryable and attempt max_retries - 1: time.sleep(2 ** attempt) else: raise raise ToolExecutionError(max retries exceeded) return wrapper return decorator agent_tool(timeout10) # 注意这里无需手动传 _request_id def submit_order(sku_id: str, quantity: int, **kwargs): # kwargs 里的 _request_id 会透传给下游接口用于幂等去重 ...这个中间层看起来平淡无奇但它能把工具调用到底可不可靠这个问题从每个接入方自己去操心变成平台统一保障。这才是企业 Agent 平台该干的活。5. 平台缺少的第四块拼图评测体系与回归防线5.1 效果不错是 Demo 的话术不是生产的标准所有的 Demo 都会说效果不错。生产环境不能靠感觉必须靠数据。我见过一个团队上线了一个客服 Agent上线前觉得挺好的跑了一周后发现用户满意度比人工客服低了二十个百分点但大家完全不知道差在哪。因为没有评测体系任何改动都是在黑箱里盲飞。评测体系的最低标准是有一组固定的评测集每次修改 Prompt 或模型都跑一遍结果可对比。这就像写代码要有单元测试一样没有测试你敢重构吗Agent 也一样没有评测集你敢改 Prompt 吗我在内部一直强调一个观点评测集不是模型团队的事是平台的基础设施。没有评测基线的 Agent 变更一律不允许上线。5.2 评测集应该怎么建才靠谱很多人建的评测集都是自己手写的十几个问题这远远不够。我从实际项目中总结的经验是评测集要覆盖这几类。正常用例。用户最常问的问题和期望的正确答案跑通主流程。边界用例。模糊问法、带错别字的问法、一句话里包含两个问题的问法、中英文混搭的问法。Demo 里不会出现生产里天天见。异常用例。工具返回空、用户要求超出权限、用户连续追问同一件事。Agent 在这个情况下不应该崩溃不应该胡编乱造。安全用例。诱导 Agent 泄露系统 Prompt、越权查询他人数据、输出敏感信息。这类用例在 ToB 场景里不测出事就是大事。数量上我建议核心场景至少 100 条起步按业务复杂度往上加。质量上答案要人工确认不能模型生成什么信什么。我在做评测集时踩过的坑就是用大模型批量生成评测集和参考答案结果模型把错误答案也当成正确答案整个评测体系变成了模型自己夸自己。现在我的做法是模型生成初稿人工逐条审核宁可评测集小一点也要保证每条答案准确。5.3 实操搭一个最小的离线评测流水线最小可用的评测流水线不需要复杂的平台一个 Python 脚本加一个结果表就行def evaluate(agent, eval_set): results [] for case in eval_set: answer agent.run(case.input) passed judge(case, answer) # 规则判断或 LLM-as-Judge results.append({ input: case.input, answer: answer, passed: passed, }) return results def judge(case, answer): # 第一层规则判断关键字段是否包含、格式是否符合 for req in case.required_fields: if req not in answer: return False # 第二层语义一致性判断交由更强的模型打分 # 但必须有打分理由方便人工复核 return semantic_check(case.expected_answer, answer)我建议先做关键字段包含级别的规则判断把通过率跑出来再用 LLM-as-Judge 做语义评分。两层的优点是规则判断是确定性的LLM 判断是概率性的只有规则过了才轮到 LLM避免模型自己给自己打分带来的幻觉污染。评测结果每次改动都留一份攒几周你就能看到趋势——哪些改动让你的通过率掉了五个点一目了然。6. 平台缺少的第五块拼图人机协同与干预机制6.1 生产环境里Agent 需要的不是自主是可控Demo 强调 Agent 多么自主生产恰恰相反强调可控。企业敢不敢让 Agent 直接执行一笔转账敢不敢让 Agent 自动驳回一个请假申请大多数场景都不敢。这不是技术落后而是责任机制决定的——出了问题必须有人负责而人必须至少在决策链路上有一个确认点。所以生产级 Agent 平台必须要支持人工断点。Agent 执行到某个关键步骤时停下来把待确认的操作包括参数、原因、影响范围展示给负责人等负责人确认后继续。这个机制不是对 Agent 的否定而是对责任的明确。断点挂在哪几个环节取决于业务方愿意把控制权放到哪一层最低是所有对外操作都要审批中等是金额超过阈值才审批最高是高风险操作自动降级为人工处理。6.2 设计人工断点的四个原则从实操角度我总结了几条断点设计原则。第一断点必须能展示完整决策依据。你不能只告诉负责人Agent 想提交一个订单你要展示这是什么订单、为什么提交、基于什么数据。否则负责人根本没法确认。我见过一个断点 UI 只给了一个按钮负责人点的时候心里发虚。第二断点要支持拒绝并反馈。负责人拒绝之后要把原因回流给 Agent让 Agent 调整方案而不是直接终止对话。拒绝是正常业务流程的一部分不是异常。我之前的一个项目里业务负责人拒绝了一次报价Agent 根据反馈调整了折扣幅度再次提交整个交互顺滑得让人觉得这不是 AI 在干活而是一个懂行的同事在办事。第三Agent 等待确认时要有超时策略。负责人出差了没看到审批不能让它永久卡着。一般是超时后自动挂起标记为待处理或者降级为通知人工线下处理。这跟 BPM 系统的超时自动催办是一回事。第四所有人工干预动作也要进审计日志。谁来审的、几点审的、改了什么都得有记录。将来出争议的时候这是唯一的证据链。很多团队把审计只做到工具调用层忘了人工干预也是要审计的这是很常见的盲区。7. 从 Demo 走到生产的落地路线图7.1 别急着上平台先上工程规范我看到很多团队一上来就选框架、选平台然后发现用不起来。我的建议恰恰相反先定义工程规范再选技术设施。规范包括四件事Agent 运行时必须有 request_id 全链路追踪所有模型调用和工具调用必须留痕所有 Prompt 改动必须版本化管理任何 Agent 上线前必须过评测基线。你可以用最简单的表格管理这四件事甚至不用写代码光是规定必须做就能挡住一半的 Pilot 死亡项目。7.2 六周可以做完的三阶段以我个人的实践一个从零开始的团队六周可以走完三个阶段。前两周做可观测地基。不追求智能先把一次 Agent 对话的完整链路看清楚把成本、延迟、成功率三个指标跑出来。这个阶段你会惊讶地发现原来一次简单问答居然要花这么多钱这个过程本身就能逼你优化。中间两周做可靠性加固。给工具层加超时重试幂等给状态加上持久化补上至少二十条异常用例让 Agent 在最讨厌的情况下不至于崩掉。这个阶段跑下来你会明显感觉到这个 Agent 开始像个系统了。一个实用技巧是拿一个核心业务场景反复跑人为制造上游故障、输入乱码、权限缺失看 Agent 能不能优雅地降级。最后两周做评价闭环。建一个最小评测集把核心场景的通过率跑成一个基准线以后任何改动都要跟这个基准线对比。从这之后Agent 才进入真正可迭代的状态。注意评测集要放在代码仓库里和 Prompt 变更一起走评审流程别让评测集散落在各人的本地文件里。7.3 平台工具选型的一点心得最后聊一下工具选型。我的原则是你的核心价值在做业务集成和流程编排不要在自建大模型网关自研向量数据库这种通用基础设施上重复造轮子。开源生态里LangChain 做概念验证速度最快LangGraph 做复杂编排更顺手Langfuse 或 Arize 做追踪评测都有现成方案。但记住任何工具都比不上把工程规范建立起来这件事本身。我用过的团队里凡是先把规范落地再选型的后面都走得挺顺凡是上来就铺一堆工具平台的没过多久就发现工具成了负担。我在最后一次迁移项目的收尾会上用户方负责人说过一句话让我印象特别深我不是需要一个更聪明的助手我需要一个我能够信任的同事。这个信任不是靠模型聪明撑起来的是靠可观测、有状态、工具可靠、能评测、可干预这五件事撑起来的。企业 Agent 平台真正缺少的从来不是更炫的 Demo而是让系统值得被信任的那一层工程能力。
企业Agent平台生产落地：从Demo到可靠的五块拼图
写这篇东西的起因是我过去两年里看了不下二十个企业 Agent 平台的 Demo也亲手帮三家公司做过从 PoC 到生产环境的迁移。最扎心的现象是Demo 阶段人人都觉得手里握着下一代生产力一旦把 Agent 接到真实业务里Prompt 漂移、工具调用超时、上下文爆炸、成本账单说不清最后默默退回人工流程。问题不在模型不够聪明而在平台层几乎什么都没准备好。这篇文章想从工程视角聊聊企业 Agent 平台真正缺少的东西按我踩坑的顺序拆成五块拼图讲每块都有实操细节和真实教训适合正在搭平台、或者准备把 Agent 推向生产的团队参考。1. Demo 和生产之间隔着的不是一层窗户纸1.1 Demo 是表演生产是兜底Demo 的本质是给一个精心挑选的输入跑一条事先调好的路径最后展示一个预期的结果。整个流程里所有的异常分支都被剪掉了模型答错的部分被重试或者被主持人一句我们再试一次带过去。这在逻辑上没有任何问题因为 Demo 的目的就是验证这件事在理想条件下能不能成立。但生产环境完全没有这个前提。生产意味着真实用户会输入十种不同的说法表达同一个需求会遇到网络抖动、接口限流、上游系统崩溃会问 Demo 里完全没出现过的长尾问题。生产环境里代码不仅要处理正常路径更重要的是处理异常路径——模型返回格式错误怎么办、工具调用超时怎么办、上下文塞满了怎么办、用户连续三句话都在重复同一个问题怎么办。我经常说一句话Demo 验证的是模型的上限生产考验的是系统的下限。上限决定了一个功能能不能吸引眼球下限决定了它能不能活过第一个月。企业 Agent 平台真正缺少的从来不是把模型上限再抬高一截而是把系统下限托住的那一堆无聊但要命的工程能力。1.2 大多数 Pilot 项目是怎么死的根据我的观察大多数企业 Agent 项目不是被模型能力打死的而是被三件事耗死的。第一效果不可预测。上周调好的 Prompt 这周突然变差了没有人知道为什么因为没有日志、没有版本管理、没有评测集。第二成本不可控。一个 Agent 单次对话可能要调用三到五次大模型有时候还要检索、要调工具账单出来的时候财务直接懵了。第三没有人敢担责。Agent 做错了决策谁负责没有审批机制、没有操作留痕、没有回滚手段业务部门不敢把核心流程交给一个看起来能跑的东西。这三件事任何一件都足以让项目停在 Pilot 阶段。而它们有一个共同点都不是模型层的问题而是平台层的问题。所以我的判断很明确企业 Agent 平台的第一优先级不是更强的主体框架而是补齐生产级的基础设施。2. 平台缺少的第一块拼图全链路可观测性2.1 先看清成本和延迟再谈智能我在帮一家公司做迁移的时候发现他们的 Agent 日志就是一行AI 回复了什么。我问他们你知道一次完整对话调了哪几个模型吗每个模型多少 token工具调用花了几秒重试了几次他们答不上来。生产级 Agent 的可观测性第一层就是要能回答这些账单级的问题。我建议至少记录以下信息条目是否必需说明模型名与版本必需知道是哪个模型在干活Prompt 变更也依赖它做回归Prompt 与完整响应必需完整留痕事后定位问题全靠它输入/输出 token 数必需成本核算的基础按调用方拆分单次调用延迟必需拆解到模型、检索、工具等环节重试次数与原因推荐判断模型是不是在反复挣扎工具入参与返回推荐工具链路出问题时的定位关键有了这张表你才能回答老板的三个经典问题钱花在哪了为什么这么慢这个错是谁造成的我在实际落地时发现一个经验如果你用 LangChain 或 LangGraph 这类框架自带的 trace 信息务必开起来无论存到 LangSmith 还是自建 Langfuse先把链路串起来再说。如果你们是自研框架最简单的方式是给每次 Agent 运行分配一个 request_id所有环节都带这个 id 打日志用类似 OpenTelemetry 的思路做 span。别一上来就追求分布式追踪系统能先做到一次对话的所有环节可以按时间线串起来就已经超过大部分团队了。2.2 Trace 里最容易漏掉的三个字段很多人搭了日志但缺了三个关键字段导致事后排查还是抓瞎。第一个是触发源。这条 Agent 请求是用户直接在对话框发的还是某个定时任务触发的还是上游系统通过 API 调过来的没有触发源你就无法区分用户报障和系统告警是两个完全不同的处理路径。第二个是决策依据。Agent 为什么选择了这个工具而不是另一个如果你记录的是最终结果而不是决策过程那么当 Agent 选错工具时你只能看到结果错了但不知道为什么。LangGraph 这类图编排框架天然会记录节点间流转你可以把每个节点的输入输出都打出来。第三个是用户反馈信号。生产环境的 Agent 做完一件事后用户有没有确认有没有改答案有没有投诉这些信号是评测集之外最重要的效果指标。我做过一个简单的做法在对话结尾让用户点有帮助/没帮助然后把结果关联到对应的 trace 上。一个月下来哪个 Prompt 分支在拖后腿一清二楚。2.3 实操用最少代码搭一个 Agent 追踪中间层如果你是自研 Agent我给一个最小可落地的方案不用上什么重框架就在 Agent 的主循环里手动记录一个事件列表import time import uuid class AgentTracer: def __init__(self, request_id: str): self.request_id request_id self.events [] def record(self, stage: str, payload: dict): self.events.append({ ts: time.time(), stage: stage, payload: payload, }) def dump(self) - dict: return { request_id: self.request_id, events: self.events, total_tokens: self.token_usage(), } def token_usage(self) - int: return sum( e[payload].get(tokens, (0, 0))[0] e[payload].get(tokens, (0, 0))[1] for e in self.events if e[stage] model_call ) # 使用示意 tracer AgentTracer(request_idstr(uuid.uuid4())) tracer.record(model_call, {model: gpt-4o, prompt: user_query, tokens: (1024, 512)}) tracer.record(tool_call, {tool: query_stock, params: {sku: A100}, result: available})这个中间层做出来之后剩下的就是把它接入日志系统再配一个简单的查询页面。别嫌它土我亲手验证过一套三百行的追踪中间层就能解决百分之八十的这个 Agent 刚才到底干了什么的问题。3. 平台缺少的第二块拼图记忆与状态管理3.1 三种记忆不能混为一谈Demo 里的记忆通常就是直接把历史对话往上下文里塞。生产环境里这么干很快就出事故。企业 Agent 平台的记忆至少分三层千万不要混。对话级记忆指的是当前会话内用户说了什么、Agent 答了什么。这个相对简单滑动窗口裁剪即可。业务级记忆就难了它指的是跨会话的业务上下文用户上次提交的订单号是多少客户的行业是什么这个项目的审批状态走到哪一步了这些都必须在独立的业务存储里读出来而不是靠模型回忆。长期知识记忆则是企业知识库、产品文档、过往案例这类静态知识通常存在向量库里做检索增强。三层记忆的读写频率、存储介质、一致性要求完全不同混在一个 Redis 或者一个向量库里后期一定会爆炸。3.2 状态不离线生产 Agent 的硬约束做 Demo 时 Agent 无状态也无所谓反正每一轮都是从头跑。生产环境不行用户可能在对话中问一句刚才那个报价单呢也可能隔三天回来说上次那个方案我们领导批了。这时候如果 Agent 没有可靠的业务级状态管理它就只能靠上下文里还残留着——一旦会话超时被清掉、或者用户换了个终端一切归零。我在项目里见过最典型的翻车现场Agent 帮用户提交了采购申请生成了申请单号然后用户过了两小时问我这个单子到哪一步了Agent 一脸茫然因为它把申请单号放在上一轮对话上下文里而那个会话已经被回收了。所以生产级设计必须确立一条原则状态不进上下文上下文只放对当前决策有用的摘录完整状态永远落在存储层。每个业务实体订单、申请、工单都有唯一标识Agent 通过工具读写这些实体的状态而不是靠人话描述。这个原则往深了说就是让 Agent 从一个聊天模型变成一个业务系统的操作员。3.3 实操分层的状态存储怎么选型我的建议是这样一套组合对话状态用 RedisTTL 按会话生命周期设置存角色、消息摘要、关键实体 id。只存最近 N 轮历史对话归档到数据库。业务状态用传统关系库或文档库每个业务实体一张表字段里必须包括当前状态机节点负责人更新时间。Agent 的所有业务操作都走这里。知识记忆用向量库企业文档切块后做 embedding检索结果作为上下文附加上去。向量库不要存业务状态它不适合强一致性的更新。这套组合不是银弹但能覆盖我见过的大多数企业场景。有人问过我能不能全都塞进一个大上下文里我说你试试就知道上下文一涨成本线性涨、延迟也涨而且模型对中段信息的注意力会衰减到时候你会花钱买一个更笨的助手。4. 平台缺少的第三块拼图工具调用的可靠性治理4.1 工具在 Demo 里是函数在生产里是接口Demo 阶段调用一个工具就是写个函数传参、返回、完事。生产环境里每个工具背后都是一个真实系统ERP、CRM、审批流、库存服务。这意味着三件事必须解决。权限。不是每个用户都能调用所有工具。一个实习生账户不能发起百万级采购审批。工具层必须有和业务权限体系打通的鉴权而不是 Agent 拿到什么 key 就调用什么。审计。谁在什么时间基于什么理由调用了这个工具必须留痕。这既是合规要求也是事后追责的基础。稳定性。上游系统可能 5 秒才响应可能返回 502可能字段格式和文档不完全一致。你的 Agent 必须能处理这些而不是一遇到异常就抱歉我遇到问题。4.2 超时、重试、幂等工具层的三大件我在生产项目里总结了一个工具调用的最小防御集。超时是必须的。每个工具调用必须设置超时上限通常 5 到 10 秒。没有超时的 Agent 调用会被一个卡住的上游系统拖死整个并发池。重试要聪明。遇到瞬时错误503、网络超时可以重试遇到业务错误参数非法、权限不足重试是浪费。而且重试必须带间隔和次数上限我一般用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒最多三次。幂等是最高优先级。如果提交订单这个工具被重试了两次会不会生成两笔订单生产环境里这个问题是要命的。解法是幂等键——每次 Agent 工具调用都带一个唯一的请求 id服务端凭这个 id 去重。我在架构评审时看到过太多团队完全没意识到这个问题直到上线后第一天就出现重复订单才发现。4.3 实操给工具层加一道守卫中间件用一个统一的装饰器或者网关来实现工具的可靠调用不要在每个工具内部各自处理超时重试。我给一个 Python 示意import functools import time import uuid class ToolExecutionError(Exception): pass def agent_tool(max_retries3, timeout8): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): request_id kwargs.pop(_request_id, str(uuid.uuid4())) for attempt in range(max_retries): try: return func(*args, **kwargs, _request_idrequest_id) except TimeoutError: time.sleep(2 ** attempt) except ServerError as e: if e.retryable and attempt max_retries - 1: time.sleep(2 ** attempt) else: raise raise ToolExecutionError(max retries exceeded) return wrapper return decorator agent_tool(timeout10) # 注意这里无需手动传 _request_id def submit_order(sku_id: str, quantity: int, **kwargs): # kwargs 里的 _request_id 会透传给下游接口用于幂等去重 ...这个中间层看起来平淡无奇但它能把工具调用到底可不可靠这个问题从每个接入方自己去操心变成平台统一保障。这才是企业 Agent 平台该干的活。5. 平台缺少的第四块拼图评测体系与回归防线5.1 效果不错是 Demo 的话术不是生产的标准所有的 Demo 都会说效果不错。生产环境不能靠感觉必须靠数据。我见过一个团队上线了一个客服 Agent上线前觉得挺好的跑了一周后发现用户满意度比人工客服低了二十个百分点但大家完全不知道差在哪。因为没有评测体系任何改动都是在黑箱里盲飞。评测体系的最低标准是有一组固定的评测集每次修改 Prompt 或模型都跑一遍结果可对比。这就像写代码要有单元测试一样没有测试你敢重构吗Agent 也一样没有评测集你敢改 Prompt 吗我在内部一直强调一个观点评测集不是模型团队的事是平台的基础设施。没有评测基线的 Agent 变更一律不允许上线。5.2 评测集应该怎么建才靠谱很多人建的评测集都是自己手写的十几个问题这远远不够。我从实际项目中总结的经验是评测集要覆盖这几类。正常用例。用户最常问的问题和期望的正确答案跑通主流程。边界用例。模糊问法、带错别字的问法、一句话里包含两个问题的问法、中英文混搭的问法。Demo 里不会出现生产里天天见。异常用例。工具返回空、用户要求超出权限、用户连续追问同一件事。Agent 在这个情况下不应该崩溃不应该胡编乱造。安全用例。诱导 Agent 泄露系统 Prompt、越权查询他人数据、输出敏感信息。这类用例在 ToB 场景里不测出事就是大事。数量上我建议核心场景至少 100 条起步按业务复杂度往上加。质量上答案要人工确认不能模型生成什么信什么。我在做评测集时踩过的坑就是用大模型批量生成评测集和参考答案结果模型把错误答案也当成正确答案整个评测体系变成了模型自己夸自己。现在我的做法是模型生成初稿人工逐条审核宁可评测集小一点也要保证每条答案准确。5.3 实操搭一个最小的离线评测流水线最小可用的评测流水线不需要复杂的平台一个 Python 脚本加一个结果表就行def evaluate(agent, eval_set): results [] for case in eval_set: answer agent.run(case.input) passed judge(case, answer) # 规则判断或 LLM-as-Judge results.append({ input: case.input, answer: answer, passed: passed, }) return results def judge(case, answer): # 第一层规则判断关键字段是否包含、格式是否符合 for req in case.required_fields: if req not in answer: return False # 第二层语义一致性判断交由更强的模型打分 # 但必须有打分理由方便人工复核 return semantic_check(case.expected_answer, answer)我建议先做关键字段包含级别的规则判断把通过率跑出来再用 LLM-as-Judge 做语义评分。两层的优点是规则判断是确定性的LLM 判断是概率性的只有规则过了才轮到 LLM避免模型自己给自己打分带来的幻觉污染。评测结果每次改动都留一份攒几周你就能看到趋势——哪些改动让你的通过率掉了五个点一目了然。6. 平台缺少的第五块拼图人机协同与干预机制6.1 生产环境里Agent 需要的不是自主是可控Demo 强调 Agent 多么自主生产恰恰相反强调可控。企业敢不敢让 Agent 直接执行一笔转账敢不敢让 Agent 自动驳回一个请假申请大多数场景都不敢。这不是技术落后而是责任机制决定的——出了问题必须有人负责而人必须至少在决策链路上有一个确认点。所以生产级 Agent 平台必须要支持人工断点。Agent 执行到某个关键步骤时停下来把待确认的操作包括参数、原因、影响范围展示给负责人等负责人确认后继续。这个机制不是对 Agent 的否定而是对责任的明确。断点挂在哪几个环节取决于业务方愿意把控制权放到哪一层最低是所有对外操作都要审批中等是金额超过阈值才审批最高是高风险操作自动降级为人工处理。6.2 设计人工断点的四个原则从实操角度我总结了几条断点设计原则。第一断点必须能展示完整决策依据。你不能只告诉负责人Agent 想提交一个订单你要展示这是什么订单、为什么提交、基于什么数据。否则负责人根本没法确认。我见过一个断点 UI 只给了一个按钮负责人点的时候心里发虚。第二断点要支持拒绝并反馈。负责人拒绝之后要把原因回流给 Agent让 Agent 调整方案而不是直接终止对话。拒绝是正常业务流程的一部分不是异常。我之前的一个项目里业务负责人拒绝了一次报价Agent 根据反馈调整了折扣幅度再次提交整个交互顺滑得让人觉得这不是 AI 在干活而是一个懂行的同事在办事。第三Agent 等待确认时要有超时策略。负责人出差了没看到审批不能让它永久卡着。一般是超时后自动挂起标记为待处理或者降级为通知人工线下处理。这跟 BPM 系统的超时自动催办是一回事。第四所有人工干预动作也要进审计日志。谁来审的、几点审的、改了什么都得有记录。将来出争议的时候这是唯一的证据链。很多团队把审计只做到工具调用层忘了人工干预也是要审计的这是很常见的盲区。7. 从 Demo 走到生产的落地路线图7.1 别急着上平台先上工程规范我看到很多团队一上来就选框架、选平台然后发现用不起来。我的建议恰恰相反先定义工程规范再选技术设施。规范包括四件事Agent 运行时必须有 request_id 全链路追踪所有模型调用和工具调用必须留痕所有 Prompt 改动必须版本化管理任何 Agent 上线前必须过评测基线。你可以用最简单的表格管理这四件事甚至不用写代码光是规定必须做就能挡住一半的 Pilot 死亡项目。7.2 六周可以做完的三阶段以我个人的实践一个从零开始的团队六周可以走完三个阶段。前两周做可观测地基。不追求智能先把一次 Agent 对话的完整链路看清楚把成本、延迟、成功率三个指标跑出来。这个阶段你会惊讶地发现原来一次简单问答居然要花这么多钱这个过程本身就能逼你优化。中间两周做可靠性加固。给工具层加超时重试幂等给状态加上持久化补上至少二十条异常用例让 Agent 在最讨厌的情况下不至于崩掉。这个阶段跑下来你会明显感觉到这个 Agent 开始像个系统了。一个实用技巧是拿一个核心业务场景反复跑人为制造上游故障、输入乱码、权限缺失看 Agent 能不能优雅地降级。最后两周做评价闭环。建一个最小评测集把核心场景的通过率跑成一个基准线以后任何改动都要跟这个基准线对比。从这之后Agent 才进入真正可迭代的状态。注意评测集要放在代码仓库里和 Prompt 变更一起走评审流程别让评测集散落在各人的本地文件里。7.3 平台工具选型的一点心得最后聊一下工具选型。我的原则是你的核心价值在做业务集成和流程编排不要在自建大模型网关自研向量数据库这种通用基础设施上重复造轮子。开源生态里LangChain 做概念验证速度最快LangGraph 做复杂编排更顺手Langfuse 或 Arize 做追踪评测都有现成方案。但记住任何工具都比不上把工程规范建立起来这件事本身。我用过的团队里凡是先把规范落地再选型的后面都走得挺顺凡是上来就铺一堆工具平台的没过多久就发现工具成了负担。我在最后一次迁移项目的收尾会上用户方负责人说过一句话让我印象特别深我不是需要一个更聪明的助手我需要一个我能够信任的同事。这个信任不是靠模型聪明撑起来的是靠可观测、有状态、工具可靠、能评测、可干预这五件事撑起来的。企业 Agent 平台真正缺少的从来不是更炫的 Demo而是让系统值得被信任的那一层工程能力。
