企业 AI Agent 领域的融资消息越来越密集。Berlin 的 Telli 刚刚完成 1500 万美元融资计划继续投入企业级 AI Agent 的研发和落地这类信号说明资本和行业都在从“能不能做 demo”转向“能不能稳定跑生产”。对企业技术团队来说真正的挑战不是再写一个能调用大模型的脚本而是把 AI Agent 变成一套可测试、可观测、可回滚、可评估的工程系统。这篇文章不以 Telli 的产品细节为主而从企业 AI Agent 工程实践的角度整理一套主线先理解 Agent 的核心机制再看开发时需要哪些组件和评估方法最后解决生产环境最关心的可靠性、成本和安全问题。适合正在做 AI Agent 原型验证、准备进入内部试点或者已经在生产环境踩坑的研发同学。1. 融资新闻背后的工程信号企业 AI Agent 进入验证期1.1 企业 AI Agent 不再是“聊天框 插件”很多团队对 Agent 的理解还停留在问答机器人用户输入一句话系统调用大模型返回一段结果。但企业级 AI Agent 的目标完全不同它要代表用户去完成一件有明确结果的任务比如处理退款流程、整理多份合同、根据监控告警自动定位故障原因并给出处置建议。这类系统不只是“生成文本”它还需要理解任务目标把模糊指令拆成可执行步骤选择工具例如查询订单库、调用内部 API、修改工单状态在多个步骤之间维护状态记录已经完成的操作和中间结果遇到失败或信息不足时主动修正全过程可被记录和审计方便事后追溯。这正是“Agent”和“聊天机器人”的分界线。聊天机器人回答“应该怎么做”Agent 要真的去做并把做过的过程讲清楚。1.2 为什么融资新闻指向工程化瓶颈Berlin 的 Telli 拿到 1500 万美元继续做企业 AI Agent这类消息在北美和欧洲市场越来越常见。资本愿意加注说明市场已经过了“验证认知”的阶段更多资金开始投向产品化、平台化和行业化。但对工程师来说融资热并不等于技术成熟。企业采购 Agent 类产品时通常最关心四个问题问题本质效果是否稳定同一类任务的成功率是否可复现结果能否评估有没有客观指标判断 Agent 做得好不好故障能否追溯出问题时能不能看到完整决策链路权限是否可控Agent 调用工具时会不会越权或误操作这些问题不是靠把 Prompt 写长就能解决的它们对应的是 Agent 架构设计、评测体系、日志链路和权限模型。换句话说融资解决的是商业问题但交付 Agent 前工程团队必须先解决可靠性问题。2. 企业 AI Agent 到底由哪些模块组成2.1 从一条用户请求看 Agent 的运行链路为了让问题具体化假设企业内部有一个“售后工单处理 Agent”。用户提交一条工单“客户反馈商品颜色发错要求补发正确颜色并补偿一张优惠券。”Agent 要完成这个任务内部大概会经历下面几个环节任务理解解析用户意图识别出需要“补发”和“发优惠券”两个动作信息收集调用订单查询工具确认订单号、商品 SKU、收货地址工具调用调用补发接口创建换货单再调用优惠券接口发放券码结果校验检查接口返回状态确认两个动作都成功结果输出生成给用户的答复文案。如果任何一个环节失败例如订单查不到、补发接口超时、优惠券已发过Agent 都需要决定是重试、换路径还是转人工。这里可以把企业 AI Agent 拆成五个核心组件大模型负责推理、生成、决策是整个系统的大脑任务规划器把目标拆解成步骤并根据执行结果动态调整工具集Agent 能触达的外部能力包括 API、数据库、搜索引擎、内部系统记忆模块保存上下文、中间状态和长期业务规则评测与护栏判断结果是否合格、行为是否越界、是否进入死循环。2.2 “LLM 推理 工具调用”是两种不同难度很多 Agent 框架会强调 Model Context Protocol、Function Calling、Tool Use 这些概念。简单理解它们都在解决同一个问题让大模型不只是“输出文字”而是“输出一个结构化的工具调用指令”由系统执行后把结果再送回给模型。入门实现往往长这样tools [ { type: function, function: { name: query_order, description: 根据订单号查询订单信息, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ]这段配置告诉模型系统里有一个查询订单的工具你可以申请调用它但真正的执行由外部代码完成。这个设计最大的价值是安全隔离模型不直接访问数据库而是通过受控接口访问。但在企业场景里难点会出现在两个地方。第一工具数量一多模型选错工具的概率会上升第二工具返回的结果可能是分页列表、复杂 JSON模型需要理解这些结构化数据再决定下一步动作。这两点决定了 Agent 的效果上限。2.3 自主性与可控性的取舍“LLM Powered Autonomous Agents”是行业里经常讨论的方向意思是 Agent 可以自主决定一连串步骤。自主性高意味着处理复杂任务能力强但也意味着失控风险高。企业落地时通常不建议一开始就追求完全自主。更稳妥的做法是分级控制自主级别行为模式适用场景单步辅助用户确认后执行一次工具调用查询数据、生成草稿流程内循环Agent 在限定流程内自动执行多步工单分类、合同信息提取目标导向Agent 自主规划并执行事后审计故障排查、跨系统数据汇总完全自主Agent 独立决策系统自动执行高风险场景暂不推荐推荐路径是从“单步辅助”开始逐步增加 Agent 可执行的步骤数同时建立完善的日志和拦截机制。生产环境的 Agent 不是越聪明越好而是越可控越好。3. 开发企业 AI Agent 之前先想清楚评估体系3.1 为什么 Agent 无法用传统单元测试覆盖传统软件测试有明确的输入与预期输出。Agent 不同它的输入是自然语言输出包含推理过程和工具调用序列。同一个问题模型可能生成多条正确路径不能简单把“和期望文本一致”当作通过标准。如果直接拿大模型的普通问答评测方法来测 Agent会遇到三个典型问题结果正确但路径不同算不算通过Agent 调错了工具但最终结果正确是否要拦截中间步骤失败后自动重试成功系统该记录成功还是失败。这些都需要设计专门的评测方案。企业 Agent 的评测不能只问“最终回答好不好”而要覆盖“任务完成度”“步骤合理性”“工具调用正确性”“错误恢复能力”等维度。3.2 评估一个 Agent 要从多个维度打分参考目前行业内对 Agent Evaluation 的讨论可以建立一套多维指标体系维度要回答的问题常见指标任务完成度目标是否最终达成完成率、关键动作覆盖率工具调用正确性是否选择了正确的工具和参数工具准确率、参数准确率路径效率步骤是否冗余平均步数、有效步骤占比错误恢复失败后能否自我修正重试成功率、替代路径成功率安全合规是否越权或违法规则越权调用次数、敏感数据暴露次数用户满意度结果是否让用户满意人工评分、采纳率这些指标不是一次性测完就结束而是要沉淀成测试集在每次模型升级、Prompt 调整、工具变更后重新回归。3.3 构造高质量评测数据集评测集的来源主要有三类线上真实请求脱敏后的历史工单、真实用户问题人工构造用例覆盖边界条件、异常情况、敏感场景自动生成用例借助大模型批量生成同一意图的多种表达。推荐以“任务级用例”为单位组织测试集。每条用例包含四部分{ case_id: case_0012, task_description: 查询订单 OD20240801001 的物流状态, expected_tool_calls: [ {name: query_order, params: {order_id: OD20240801001}}, {name: query_logistics, params: {order_id: OD20240801001}} ], expected_result: 返回最新物流节点和预计送达时间, risk_tags: [涉及用户隐私, 查询类操作] }评测时Agent 实际产生的工具调用序列会和期望序列做比对。即使最终答案被用户接受如果工具调用序列偏离预期也应进入分析列表因为这类偏差可能隐藏越权或误操作风险。4. 搭建一个最小可运行的企业 AI Agent4.1 目录结构与技术选型企业开发 Agent 不一定非要使用特定框架。如果团队没有历史包袱可以从一个最小结构开始先跑通完整链路再替换组件。enterprise-agent/ ├── app/ │ ├── agent/ │ │ ├── planner.py # 任务拆解 │ │ ├── executor.py # 工具执行 │ │ ├── memory.py # 状态和上下文管理 │ │ └── guardrails.py # 合规校验 │ ├── tools/ │ │ ├── order_api.py # 订单查询工具 │ │ └── ticket_api.py # 工单系统工具 │ ├── llm/ │ │ ├── client.py # LLM 客户端封装 │ │ └── prompts.py # Prompt 统一管理 │ └── server.py # 对外服务入口 ├── tests/ │ ├── cases/ │ └── evaluate.py # 评测入口 ├── config.yaml └── README.md这个目录结构的关键点是“工具独立”“Prompt 独立”“评测独立”避免把所有逻辑都堆在服务入口里。4.2 核心循环感知、决策、执行、观测Agent 的运行主循环可以抽象为四个步骤def run_agent(task: str, max_steps: int 8): context {task: task, history: [], state: {}} for step in range(max_steps): # 1. 感知与决策让模型判断下一步动作 action decide_next_action(context) # 2. 护栏检查执行前先校验是否允许 guardrail_result check_guardrails(action) if not guardrail_result[allowed]: context[history].append(guardrail_result[reason]) break # 3. 执行工具 observation execute_tool(action) # 4. 记录并更新上下文 context[history].append(action) context[history].append(observation) context[state].update(observation.get(state_change, {})) if action[type] final_answer: return observation return {success: False, reason: max_steps_exceeded}这里要特别注意“护栏检查”的位置。它必须在工具执行之前做不能等到调用完再验证。只要发现 Agent 要调用未授权工具就应终止或者转人工。4.3 工具层是所有信任的边界Agent 的工具层是企业系统与外部世界的连接点也是风险最高的一层。工具实现至少要包含四部分参数校验检查模型传入的参数是否合法权限校验确认当前会话是否有调用权限结果裁剪避免把敏感字段全部返回给模型错误码映射把底层异常转成 Agent 能理解的错误信息。def query_order(order_id: str, operator: str): if not check_permission(operator, order:query): return {error: FORBIDDEN, message: no permission} order order_repo.find(order_id) if not order: return {error: NOT_FOUND, message: order not found} return { order_id: order.id, sku: order.sku, status: order.status, # 注意不返回完整用户地址、支付信息等敏感字段 }工具返回给模型的数据应该最小化。模型不需要知道所有字段只需要知道完成推理所需的信息。这样能降低敏感字段泄露到 Prompt 和日志中的风险。5. Agent 的可靠性从哪几个方向提升5.1 用结构化方式降低模型自由发挥空间大模型在开放对话中表现很好但在 Agent 任务中自由发挥反而是风险。企业场景里更推荐给模型提供“强结构”的指令让每一步输出都符合固定协议。例如决策输出建议固定成 JSON 结构{ thought: 用户要求查订单先调用订单查询工具, tool: query_order, params: { order_id: OD20240801001 }, type: tool_call }工具层收到这段 JSON 后优先执行tool和params字段thought字段只用于日志分析。这种做法的好处是即使模型出现了“幻觉”错误也会被限制在结构化字段里方便程序做校验。5.2 引入验证节点不让 Agent 一条路走到黑很多 Agent 失败是因为“一步错步步错”。解决方案是在关键节点增加验证器例如参数合法性校验工具调用前确认必填字段业务规则校验例如退款金额不能超过订单原价结果状态校验接口返回成功后再查一次确认状态是否真的变更。可以把校验器看成一个独立于大模型的规则层。凡是能用确定性代码判断的就不要让模型决定。模型只负责需要理解和推理的部分其余全部交给规则。5.3 建立重试与替代路径机制Agent 在生产环境一定会遇到接口超时、数据为空、模型输出格式异常等问题。不要假设一次执行会成功建议内置重试机制工具调用失败区分可重试错误与不可重试错误模型输出解析失败要求模型重新输出并附上前一次输出的错误原因工具返回空结果让模型判断是换关键词、查关联数据还是直接说明找不到达到最大步数停止循环保留上下文转给人工处理。一个有效的替代路径是“降级为普通对话助手”。当 Agent 连续三次无法完成工具调用时可以切换成只回答不执行操作的模式避免系统无限循环。6. 企业级 Agent 的权限、安全与成本控制6.1 权限模型Agent 不能比用户权限更大一个常见错误是让 Agent 使用服务账号调用所有系统接口这会把权限问题全部抹平。正确做法是“用户权限穿透”即 Agent 执行的每个操作都要继承发起者的权限范围。具体落地时可以这样设计请求进入时携带用户身份工具层从上下文中读取用户身份每次调用前执行权限断言涉及变更操作时要求二次确认或限制执行时间窗口。def current_user() - UserContext: return get_from_request_context() def check_permission(user: UserContext, action: str) - bool: return user.has_permission(action)同时要记录“谁在什么时间让 Agent 执行了什么操作”。这些审计日志不是可选项而是企业上线 Agent 的前置条件。6.2 防止 AI Agent 输出越界内容行业里经常讨论“AI 去违禁词”“无禁止聊天”之类的话题本质都是要给大模型输出加上护栏。企业 Agent 面对的约束比公开聊天更严格因为输出直接进入业务系统错误回答可能带来实际损失。输出护栏可以从四个层面做Prompt 层面明确要求模型不得输出金融、医疗、法律等专业结论除非有明确授权模型层面选择支持企业级安全配置的模型服务代码层面对输出做关键词、敏感信息、PII 检测人工层面高风险动作默认进入人工审批队列。需要注意的是没有任何护栏是百分之百的。最有效的方法是把 Agent 的“权限”和“责任”划到最小范围让它只做它被授权做的事。6.3 成本控制的三个抓手Agent 和普通问答的最大成本差异在于多步调用。一个任务可能触发 5 到 10 次模型请求推理成本会成倍增加。要控制成本可以从三个角度入手抓手做法收益减少无效步骤先让脚本处理确定逻辑只把真正需要理解的任务交给模型降低模型调用次数使用缓存相同问题、相同上下文直接命中缓存降低重复调用成本区分模型等级简单任务用小模型复杂推理用大模型优化单次成本建议在 Agent 架构里增加“成本追踪”字段每次调用都记录模型名称、输入 Token、输出 Token 和耗时。上线前先跑 200 条真实任务估算一个平均成本再决定业务定价和资源配额。7. 常见问题排查Agent 没结果时先查哪一层7.1 排查顺序按照调用链路倒查Agent 一旦出问题很多人第一反应是调 Prompt。实际推荐顺序是先确认用户输入到达服务端请求没有被网关、接口层截断再确认 LLM 响应是否正常是否出现超时、限流、内容审核拦截然后检查模型决策输出是否被解析成功接着检查工具层日志确认工具是否真的被执行最后看上下文里有没有遗漏关键信息。下面这个表格可以当排查清单用现象可能原因检查位置Agent 没有返回结果模型调用超时LLM 网关日志Agent 不调用工具直接回答工具描述或 Prompt 不清模型决策日志工具调用参数错误模型提取参数不完整工具入参校验日志工具执行失败但 Agent 没感知工具异常被吞掉工具层异常捕获最终结果不符合预期上下文缺信息或规则冲突完整对话链路回放Agent 进入死循环缺少最大步数限制步数限制和循环日志成本突然升高工具返回大量无用数据Token 消耗统计7.2 快速定位 Prompt 与工具定义的问题如果模型该调用工具时没调用先检查工具定义是否清晰。一个常见坑是工具的description写得像产品文档没有写出“什么场景下用这个工具”。推荐描述模板name: query_order description: 当用户需要查询订单状态、物流进度、商品信息时使用。 必须提供 order_id 参数。如果用户没有提供订单号先询问用户。 不要用这个工具查询客户个人资料。把“触发条件”“必填参数”“不要做什么”都写清楚模型选错工具的概率会明显下降。7.3 日志体系是 Agent 排错的核心资产Agent 排错不能只看最终结果必须能看到完整决策链路。建议每个 Agent 请求都输出结构化日志{ request_id: req_9f3a2b, user_id: staff_1024, input: 查询订单 OD20240801001 的物流状态, steps: [ { step: 1, type: tool_call, tool: query_order, params: {order_id: OD20240801001}, result_summary: order found, cost_tokens: 342, latency_ms: 210 }, { step: 2, type: final_answer, content: 订单已发货当前物流节点杭州转运中心, cost_tokens: 126, latency_ms: 180 } ], total_cost_tokens: 468, total_latency_ms: 390 }有了这份日志排查时就不需要靠猜。把请求 ID 和日志关联起来无论是还原现场还是做评测集数据收集都会轻松很多。8. 从原型到生产企业 AI Agent 的落地路线8.1 三个阶段逐步推进企业引入 AI Agent不建议一次性铺开到全部业务。推荐分三个阶段阶段一内部试点。选定一个低风险、高频、效果容易评估的流程比如知识库问答、工单自动分类、数据查询助手。目标是跑通工程链路积累评测数据。阶段二受限生产。开放给少量业务部门使用保留人工审核环节Agent 只做建议和草稿不做最终决策。目标是验证成功率、用户接受度和成本模型。阶段三规模化。在评测通过后逐步扩大 Agent 的自主权限接入更多工具建立自动监控和告警机制。8.2 上线前检查清单企业 Agent 上线前建议逐项确认以下内容评测集是否覆盖核心场景和边界异常是否统计了平均成功率、工具调用准确率Agent 的最大步数和超时时间是否有限制工具层是否做了最小化数据返回是否实现了用户权限穿透高风险操作是否需要二次确认全链路结构化日志是否完整是否有成本追踪和 Token 消耗统计是否有上线后回滚方案是否有人工接管流程和转交机制。只要有一项没有完成就不建议直接开放给生产用户。8.3 下一步可以深耕的方向对于已经跑通基础 Agent 的团队后续有四个扩展方向值得关注评估体系自动化把人工评测逐步升级为自动回归流水线多 Agent 协作拆分成“规划 Agent”“执行 Agent”“审核 Agent”让各角色职责更单一经验积累与 Agent 自改进把历史成功和失败案例沉淀成规则库辅助模型决策行业化模板针对客服、运维、人力、财务等场景沉淀可复用的工具集和 Prompt 模板。9. 最后的实践建议企业 AI Agent 的交付难点不在模型而在系统设计。大模型负责理解自然语言和生成步骤真正保证结果正确、过程可控、故障可查的是工具层、评测体系、护栏和日志机制。从 Berlin 的 Telli 这类融资消息能看到行业方向但回到自己的项目上运营开发者的做法应该是先用最小闭环跑通业务场景把评估指标立起来再逐步扩大 Agent 的自主权。不要一开始就追求“全自动”先把一次“单步工具调用”做扎实比任何花哨规划都更有价值。对正准备进入这个领域的团队建议从内部工单、报表查询、知识检索这类低风险场景开始。先把项目跑起来把日志和评测积累起来再用数据决定哪些任务适合提升自主级别。Agent 工程化不是一次改造而是一套持续叠加可信层的过程。