企业官网建设流程全解析

在企业 AI Agent 的落地浪潮里，“评估” 是最容易被低估的一环。最近 Berlin 的 Telli 宣布完成 1500 万美元融资，目标很明确：把企业级 AI Agent 往规模化方向推进。这类融资消息越来越多，背后其实有一个共同信号——企业不再满足于让模型“能聊天”，而是要求 Agent“能干活、能验收”。

本文围绕企业 AI Agent 的工程化落地展开，重点拆解三个问题：

• 企业 AI Agent 和聊天机器人到底有什么本质区别；
• 为什么“评估（evals）”是企业级 Agent 从 Demo 走向生产环境的必经关卡；
• 如何用一套可运行的评估框架，量化衡量 Agent 的工具调用、回答质量和任务完成度。

适合的读者包括：正在做 AI Agent 项目、准备引入 RAG 或 Function Calling、但苦于不知道如何验收效果的后端工程师、算法工程师和项目负责人。文章会给出完整可复现的代码示例，运行环境以常见版本为准，具体版本可以根据你的项目实际情况调整。

1. 背景与核心概念

1.1 企业 AI Agent 是什么

先看一个直观对比。

普通的聊天机器人，核心能力是“生成一段合理文本”。你问它“帮我查一下这个订单到哪了”，它能给你一个话术模板，甚至能编一个看似合理但并未真正访问订单系统的答案。

企业 AI Agent 则完全不同。它的目标不是“回答”，而是“完成任务”。同样是“查订单”这个需求，企业 Agent 会经历这样的过程：

1. 理解用户意图，识别出这是一个“订单查询”任务。
2. 从可用工具中选择订单查询接口。
3. 提取订单号、用户身份等必要参数。
4. 调用真实的订单系统，获取实时物流状态。
5. 把结构化数据整理成用户易读的回复。
6. 判断是否还有后续操作，例如提醒退款或转人工。

这里的关键差异在于：Agent 会调用外部工具，会访问真实业务数据，并且需要对自己的行为负责。

专业一点说，企业 AI Agent 是一个以大语言模型（LLM）为“大脑”，通过规划（Planning）、工具调用（Tool Use）、记忆（Memory）和反馈（Feedback）等机制，在真实业务环境中完成多步任务的智能系统。

1.2 企业 AI Agent 的典型工作流程

企业级 Agent 的工作流程可以抽象成下面这样：

用户输入 -> 意图识别 -> 任务规划 -> 工具调用 -> 结果解析 -> 生成回复 -> 用户反馈 ^ | | v +---------------- 多轮迭代 <--------------+

流程说明：

• 意图识别：判断用户想做什么，这一步决定了后续走哪个流程。
• 任务规划：将一个大任务拆解成若干小步骤，例如“查订单”需要先“确认身份”，再“查物流”，最后“生成回复”。
• 工具调用：调用 API、数据库、知识库或内部系统。这是 Agent 和企业业务结合的关键点。
• 结果解析：把工具返回的 JSON、表格、文本等数据整理成模型可理解的信息。
• 生成回复：基于工具结果生成面向用户的最终答案。
• 多轮迭代：如果中间某一步失败或信息不足，Agent 需要重新规划或追问用户。

在企业环境中，这个流程必须可追踪、可审计、可重复。这也是为什么“评估”不能只停留在最终答案层面，而需要覆盖整个执行链路。

1.3 为什么评估是规模化落地的关键

任何技术从 Demo 到生产，都要回答一个问题：怎么证明它有效？

对传统软件来说，答案是单元测试、集成测试和监控告警。但对 AI Agent 来说，事情复杂得多：

• 同样的输入，模型输出可能每次都不完全一样；
• 多个步骤之间可能互相影响，单测通过了，连起来却出错；
• 工具返回的数据格式可能变化，导致 Agent 在解析阶段失败；
• 模型的“判断”失误，很难用传统断言来捕获；
• 业务方想知道“这个 Agent 到底提升了多少效率”，而不是“感觉还可以”。

正因为这些原因，企业 AI Agent 的评估（evals）必须被当作一项工程来建设，而不是开发完顺手跑几个用例就结束。

2. 环境准备与版本说明

2.1 运行环境

本文的评估框架示例以 Python 为例，核心要求如下：

• Python 3.9 及以上版本，建议使用 3.10 或 3.11；
• 需要安装 openai 库（用于调用大模型 API），版本以官方最新稳定版为准；
• 如果没有 OpenAI API Key，也可以使用其他兼容 OpenAI 接口格式的模型服务，只需修改 base_url 和 api_key 即可。

需要特别说明：不同 SDK 版本的 API 参数会有差异。本文示例以常见的 OpenAI Python SDK 写法演示“评估框架”的思路，如果你使用其他模型服务，请按官方文档调整模型名称和客户端初始化方式。

2.2 项目结构

为了方便理解，我们把示例项目按下面结构组织：

agent-eval-demo/ ├── requirements.txt ├── agent.py ├── eval_data.jsonl └── evaluate.py

各文件职责：

• requirements.txt：依赖清单；
• agent.py：最小可运行的 Agent 实现；
• eval_data.jsonl：评估数据集，每行是一条带标注的测试用例；
• evaluate.py：评估脚本，读取数据集、运行 Agent、统计指标并输出报告。

2.3 依赖安装

先准备依赖文件：

# requirements.txt openai>=1.0.0

然后在项目目录下执行：

pip install -r requirements.txt

如果网络环境使用内部镜像源，可以这样安装：

pip install -r requirements.txt -i https://pypi.org/simple

安装完成后，建议先确认 SDK 版本：

python -c "import openai; print(openai.__version__)"

不同版本之间的细微差异不会影响本文的核心结构，但如果你遇到“方法不存在”之类的报错，优先检查 SDK 版本是否过旧。

3. 企业 Agent 的核心模块拆解

在写评估框架之前，先梳理 Agent 本身的设计。一个可评估的 Agent，首先必须是一个结构清晰的 Agent。

3.1 规划模块

规划模块负责把用户请求拆解成可执行的步骤。常见做法有：

• Prompt 内让模型直接输出“步骤清单”；
• 使用 ReAct 模式，让模型在思考、行动、观察之间循环；
• 使用更复杂的规划器，根据任务类型动态生成子任务。

在企业场景中，规划不必追求复杂。很多生产级 Agent 用的都是“有限状态机 + 模型选择”的混合方案：预定义好固定的业务流程，模型只在关键节点做判断。这样做的最大好处是：可评估、可回溯。

如果每个 Agent 都完全自由发挥，评估时你会发现连“步骤对不对”都很难定义。所以在评估体系中，规划结果要先做结构化的意图和步骤匹配。

3.2 工具调用模块

工具调用是 Agent 与企业业务系统交互的桥梁。常见的工具类型包括：

• 查询类工具：查订单、查库存、查用户信息；
• 写操作类工具：创建工单、修改状态、发送通知；
• 检索类工具：从知识库中召回相关文档；
• 计算类工具：价格计算、报表聚合。

工具调用的正确性，是 Agent 评估中最关键也最容易出错的部分。你需要评估：

• 工具是否被正确选中；
• 参数是否完整、格式是否正确；
• 工具返回结果是否被正确解析；
• 工具调用失败后是否有合理的降级策略。

3.3 记忆与上下文

多轮对话中，Agent 需要记住用户说过的信息，也要避免把错误信息带入后续步骤。企业级 Agent 的记忆通常分为：

• 短期记忆：当前会话的上下文，在请求之间通过 messages 传递；
• 长期记忆：用户画像、历史订单、偏好设置等，通常存储在外部的数据库或向量库中。

在评估时，要注意区分“模型上下文长度导致的截断”和“记忆逻辑本身的缺陷”。前者可以通过调整窗口或摘要策略缓解，后者则需要修改记忆设计。

3.4 执行与反馈

Agent 执行完工具调用后，需要根据反馈决定下一步动作。这里有两个常见问题：

一是“沉默失败”。工具调用失败后，Agent 不告诉用户，而是继续生成一个看似正常的回答。这在企业环境中非常危险，因为你无法判断回答到底有没有真实数据支撑。

二是“无限重试”。模型发现自己调用失败后，可能不断尝试相同或类似的工具，造成资源和成本浪费。

所以，评估执行链路时，不仅要看“最终回答对不对”，还要看“执行过程中是否有异常被合理处理”。

4. AI Agent 评估体系：从指标到方法

4.1 不要只盯着准确率

传统机器学习里，准确率是一个直观指标，但企业 AI Agent 是一个多步骤系统，“最终答对”并不等于“过程正确”。

举个例子：

用户问：“帮我把订单 A 的地址改成北京市朝阳区 XX 路 1 号。”

Agent 可能出现以下几种情况：

• 正确调用修改接口，返回成功；
• 没有调用修改接口，但回复“已修改”（幻觉）；
• 调用了查询接口，但没有调用修改接口；
• 调用了修改接口，但参数中地址被截断；
• 正确调用了修改接口，但回复信息把新旧地址弄混。

这些情况如果用“准确率”一个指标去衡量，信息量远远不够。

合理的指标应该分维度设计：意图识别是否准确、工具选择是否准确、参数填充是否完整、最终回复是否基于工具结果、用户目标是否达成、整个流程是否有风险操作。

4.2 评估维度

企业 AI Agent 评估建议覆盖以下维度：

这里重点解释“工具调用正确性”。检查工具调用，建议至少看三层：

1. 工具名对不对；
2. 参数名和参数值对不对；
3. 工具执行后的结果有没有被正确使用。

4.3 评估方法

目前业界常用的 Agent 评估方法有四种。

第一种：规则校验。对工具调用、参数格式等结构化信息使用断言式检查。这个方法简单可靠，适合检查“调了哪个工具”“参数是否缺失”这类问题。

第二种：数据集离线评估。准备一组带标注的测试用例，批量运行 Agent，统计各项指标。这是上线前的核心评估手段。

第三种：LLM-as-a-Judge。用一个强模型作为裁判，对 Agent 的回复进行打分或判断。适合评估“回答是否自然”“是否满足用户需求”这类难以用规则定义的问题。需要注意裁判模型本身也有偏见和误差，通常建议结合人工抽样。

第四种：线上日志回流评估。Agent 上线后，将真实运行日志采样保存，每天或每周回放评估，用来发现数据漂移、规则变化和模型退化问题。

完整的评估体系，应该把这四种方法组合起来使用，而不是只依赖某一种。

4.4 评估数据集的构建与维护

评估数据集是评估体系的底座。数据集中的每一条用例，至少要包含：

• 用户输入；
• 期望的意图或任务类型；
• 期望被调用的工具；
• 期望的参数内容（或参数约束）；
• 期望的最终回复状态（成功/失败/转人工）；
• 可选的参考回复。

构建评估数据时要注意：

• 覆盖常见场景，也要覆盖边界场景；
• 包含负样本，比如用户输入不完整、用户要求超出权限范围；
• 定期从线上真实日志中补充新用例；
• 不要只收集模型“答得好”的样本，那样会把评估集变成“幸存者偏差”样本。

5. 实战：搭建一个可运行的 Agent 评估框架

这一节我们用一个“客户工单助手”的场景，完整跑通 Agent 实现、评估数据集、评估脚本和结果输出。

5.1 场景定义

假设企业内部的客服 Agent 需要支持三类操作：

1. 查询订单状态；
2. 创建售后工单；
3. 查询常见问题。

所有工具都是模拟实现，目的是演示“Agent 如何调用工具 + 评估如何判断工具调用是否正确”。如果你要接入真实系统，只需要把工具函数内部替换成真实的 HTTP 请求或数据库查询。

5.2 实现最小 Agent

文件路径：agent.py

import json from openai import OpenAI class SimpleAgent: """一个最小可运行的 Agent 示例。 主要演示三件事： 1. 如何根据用户输入选择工具； 2. 如何解析模型返回的工具调用； 3. 如何把工具结果交给模型生成最终回复。 """ def __init__(self, api_key, base_url=None, model="gpt-4o-mini"): self.client = OpenAI(api_key=api_key, base_url=base_url) self.model = model def _tool_query_order(self, order_id: str) -> dict: """模拟查询订单状态。""" mock_orders = { "A1001": {"status": "已发货", "logistics": "顺丰速运"}, "A1002": {"status": "待付款", "logistics": ""}, } return mock_orders.get(order_id, {"status": "未找到订单"}) def _tool_create_after_sale(self, order_id: str, reason: str) -> dict: """模拟创建售后工单。""" return { "ticket_id": "TS-20250101-001", "order_id": order_id, "reason": reason, "status": "已创建", } def _tool_faq(self, question: str) -> dict: """模拟常见问题检索。""" faq_map = { "退款": "退款会在 3 到 7 个工作日内原路返回。", "发货": "每日 16:00 前支付的订单当天发出。", } for key, answer in faq_map.items(): if key in question: return {"answer": answer} return {"answer": "抱歉，暂时没有找到对应答案，建议转人工。"} def _call_llm(self, messages, tools): response = self.client.chat.completions.create( model=self.model, messages=messages, tools=tools, tool_choice="auto", ) return response.choices[0].message def run(self, user_input: str): tools = [ { "type": "function", "function": { "name": "query_order", "description": "查询指定订单的状态和物流信息", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单号"} }, "required": ["order_id"], }, }, }, { "type": "function", "function": { "name": "create_after_sale", "description": "为指定订单创建售后工单", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单号"}, "reason": {"type": "string", "description": "售后原因"}, }, "required": ["order_id", "reason"], }, }, }, { "type": "function", "function": { "name": "faq", "description": "查询常见问题", "parameters": { "type": "object", "properties": { "question": {"type": "string", "description": "问题文本"} }, "required": ["question"], }, }, }, ] messages = [{"role": "user", "content": user_input}] message = self._call_llm(messages, tools) trace = [] # 循环处理模型发起的工具调用 while message.tool_calls: messages.append(message.model_dump()) for tool_call in message.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) if fn_name == "query_order": tool_result = self._tool_query_order(fn_args["order_id"]) elif fn_name == "create_after_sale": tool_result = self._tool_create_after_sale( fn_args["order_id"], fn_args["reason"] ) elif fn_name == "faq": tool_result = self._tool_faq(fn_args["question"]) else: tool_result = {"error": f"unknown tool: {fn_name}"} trace.append( { "tool": fn_name, "arguments": fn_args, "result": tool_result, } ) messages.append( { "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(tool_result, ensure_ascii=False), } ) message = self._call_llm(messages, tools) return { "final_answer": message.content, "tool_trace": trace, }

这段代码有几个设计点需要说明：

• while message.tool_calls是核心循环。模型只要想调用工具，就会返回tool_calls，Agent 执行工具后再把结果返回给模型，直到模型生成最终文本回复。
• 每次工具调用的参数都以 JSON 格式传入，模拟真实 API 调用。
• tool_trace会把每一步工具调用记录下来。这个 trace 在评估阶段非常重要，我们可以直接判断“有没有调用预期工具”“参数是否合理”。

5.3 构建评估数据集

文件路径：eval_data.jsonl

{"user_input": "帮我查一下订单 A1001 到哪里了", "expected_tool": "query_order", "expected_params": {"order_id": "A1001"}, "expected_keywords": ["已发货"]} {"user_input": "订单 A1002 我想退款，帮我创建售后工单", "expected_tool": "create_after_sale", "expected_params": {"order_id": "A1002"}, "expected_keywords": ["已创建"]} {"user_input": "一般多久能发货", "expected_tool": "faq", "expected_params": {}, "expected_keywords": ["当天"]} {"user_input": "你好", "expected_tool": null, "expected_params": {}, "expected_keywords": []}

这里每行代表一个测试用例。expected_tool表示模型应该调用的目标工具；expected_params是期望参数；expected_keywords是最终回复中应该出现的关键词。

注意：为了演示方便，参数检查只做了最简单的包含关系。真实项目中建议用更严格的字段级校验，例如正则匹配订单号格式。

5.4 编写评估脚本

文件路径：evaluate.py

import json from agent import SimpleAgent def load_eval_data(path: str) -> list: with open(path, "r", encoding="utf-8") as f: return [json.loads(line) for line in f if line.strip()] def check_tool_call(trace: list, expected_tool: str, expected_params: dict) -> bool: """检查工具调用是否符合预期。""" if expected_tool is None: return len(trace) == 0 for step in trace: if step["tool"] == expected_tool: params_ok = True for key, value in expected_params.items(): if key not in step["arguments"]: params_ok = False break if value and str(step["arguments"][key]) != str(value): params_ok = False break if params_ok: return True return False def check_keywords(answer: str, keywords: list) -> bool: """检查最终回复是否包含关键词。""" if not keywords: return True return all(kw in answer for kw in keywords) def main(): api_key = "your-api-key" base_url = None # 如使用兼容接口，可填写 base_url agent = SimpleAgent(api_key=api_key, base_url=base_url) eval_data = load_eval_data("eval_data.jsonl") total = len(eval_data) tool_ok = 0 keyword_ok = 0 all_ok = 0 details = [] for case in eval_data: result = agent.run(case["user_input"]) tool_match = check_tool_call( result["tool_trace"], case["expected_tool"], case["expected_params"], ) keyword_match = check_keywords( result["final_answer"], case["expected_keywords"], ) is_pass = tool_match and keyword_match if tool_match: tool_ok += 1 if keyword_match: keyword_ok += 1 if is_pass: all_ok += 1 details.append( { "case": case["user_input"], "tool_match": tool_match, "keyword_match": keyword_match, "pass": is_pass, "trace": result["tool_trace"], "answer": result["final_answer"], } ) print("=" * 60) print("Agent Evaluation Report") print("=" * 60) print(f"总用例数: {total}") print(f"工具调用正确率: {tool_ok / total:.2%}") print(f"回复关键词命中率: {keyword_ok / total:.2%}") print(f"整体通过率: {all_ok / total:.2%}") print("\n详细结果:") for d in details: print(f"- {d['case']}") print(f" 工具匹配: {d['tool_match']}") print(f" 关键词匹配: {d['keyword_match']}") print(f" 是否通过: {d['pass']}") print(f" 工具轨迹: {d['trace']}") print() if __name__ == "__main__": main()

5.5 运行与输出解读

将 API Key 配置好之后，运行：

python evaluate.py

预期输出结构如下：

============================================================ Agent Evaluation Report ============================================================ 总用例数: 4 工具调用正确率: 75.00% 回复关键词命中率: 75.00% 整体通过率: 50.00%

这里还能看到每条用例的详细工具轨迹。如果某条用例工具匹配失败，可以直接从轨迹里看到模型是否选错了工具，或者参数抽取是否不完整。

建议先跑通完整流程，再逐步扩充用例。评估框架的核心价值不是一次性给出“通过/不通过”，而是帮助你快速定位“哪一步出了问题”。

6. 常见问题与排查思路

排查时，建议按这个顺序来：

1. 先看工具轨迹：模型到底调用了哪个工具、传了什么参数；
2. 再看工具返回结果：外部系统是否返回了预期数据；
3. 最后看最终回答：模型是否基于工具结果生成了回复。

大部分问题都可以通过这三个层面定位。

7. 最佳实践与工程建议

7.1 评估先行，再谈优化

不要让 Agent 在“感觉不错”的状态下直接上线。先定义好核心场景和评估指标，再开始开发。每改一次 Prompt、工具定义或模型版本，都跑一遍评估集，用数据判断改动是正向还是负向。

对于企业项目，建议把评估命令写进 CI/CD 流程。每次合并代码前，自动运行一轮回归评估，防止“改了一个工具，崩了另一个场景”。

7.2 区分离线评估与线上巡检

离线评估解决“有没有能力”的问题，线上巡检解决“有没有稳定运行”的问题。

建议搭建两条评估链路：

• 离线链路：固定测试集，每次发布前运行；
• 在线链路：从生产日志中按比例采样，每日或每周回放，监控指标波动。

在线巡检时，特别要注意工具接口的返回结构变化。真实业务系统中，字段改名、状态码变化、接口超时都很常见，这些都会直接影响 Agent 表现。

7.3 人工抽样和自动评估结合

LLM-as-a-Judge 可以节省大量人力，但它不是万能的。裁判模型可能偏爱某种表达风格，可能对长文本判断不准确，也可能受到提示词轻微改动的影响。

建议在每轮评估中保留 10% 到 20% 的人工抽样。重点检查三类数据：

• 自动评估判定为“通过”但业务方觉得不对劲的样本；
• 自动评估判定为“失败”但实际处理得不错的样本；
• 涉及权限、资金、敏感信息等高风险操作的样本。

7.4 工具层设计要可观测

每个工具都要有清晰的名称、描述、入参说明和出参结构。生产环境中，建议在工具调用前后打印结构化日志，包含：

• 调用时间；
• 工具名称；
• 入参；
• 出参摘要；
• 错误信息；
• 耗时。

这些日志不仅是排查问题的依据，也是后续构建线上评估数据集的重要来源。

7.5 安全与合规边界

企业 Agent 一旦接入内部系统，就必须考虑权限边界。建议遵循最小权限原则：Agent 能调用的工具，只包含完成任务所必需的能力。

在评估集中加入“越权请求”类用例，例如：

• 用户要求查看他人订单；
• 用户要求修改价格；
• 用户要求绕过审批流程。

这些用例不必追求模型“拒绝”的措辞完美，但必须保证 Agent 不会真的执行风险操作。对疑似风险操作，优先转人工，而不是让模型自行判断。

7.6 成本控制

Agent 的成本主要由三部分构成：模型调用次数、输入输出 token 数量、工具和外部服务调用费用。

建议在评估报告中加入成本指标：

• 每个任务平均调用模型次数；
• 每个任务平均输入和输出 token 数量；
• 每个任务平均工具调用次数；
• 限制最大工具迭代轮数。

当成本异常上升时，优先检查是不是出现了“无意义循环”或“长上下文重复传递”。

8. 总结与后续学习方向

这篇文章从 Berlin 的 Telli 融资消息切入，聊了企业 AI Agent 的本质区别、核心模块、评估维度，并提供了一个可运行的 Agent 评估框架。现在回顾一下关键收获：

• 企业 AI Agent 的核心不是“生成文本”，而是“完成任务”；
• 评估不能只看最终答案，要看意图识别、工具调用、参数填充、回复生成整条链路；
• 规则校验、离线评估、LLM-as-a-Judge、线上日志回流四种方法需要组合使用；
• 评估集需要持续维护，从线上真实日志中补充样本；
• 安全与成本必须纳入评估指标，不能只追求“答得好”。

下一步比较推荐这样动手验证：把你手头最容易出错的 30 到 50 个真实用户问题整理成 JSONL 评估集，跑一个最小 Agent，先不做任何复杂优化，只统计“工具调用正确率”和“最终回复成功率”。你会发现，很多问题根本不是模型能力不够，而是工具设计不合理、参数约束不清晰、反馈信息不完整。

把这些细节补齐之后，再逐步引入更复杂的评估方法，比如 LLM-as-a-Judge、多轮一致性检查和线上日志回流。评估体系一旦跑起来，Agent 的迭代速度会比“凭感觉调 Promot”快得多。希望这篇文章能在你的企业 AI Agent 落地过程中，少走一些弯路。