企业官网建设流程全解析

柏林 AI 初创公司 Telli 最近完成了一笔 1500 万美元融资，方向是扩展企业级 AI Agent。单独看这笔钱的规模，放在整个 AI 融资周期里不算最大，但信号很明确：资本开始把 AI Agent 从“能聊天的玩具”推向企业内部生产环境。

企业级 AI Agent 和普通 AI 聊天的最大区别是：它必须能被评估。一个 Agent 能不能稳定完成真实业务任务、调用工具是否准确、出现幻觉的概率有多高、一次任务要消耗多少 token 和成本，这些问题都不能靠感觉回答。所以这篇文章不聊融资八卦，而是从工程落地角度，把企业 AI Agent 从选型、评测、部署、接口调用到故障排查的完整链路拆开。

如果你所在团队正在评估要不要引入企业 AI Agent，或者已经试点但效果不稳定，这篇文章值得直接收藏。我们重点解决三件事：第一，Agent 上线前应该怎么做评测；第二，企业级部署架构和 API 接入怎么设计；第三，生产环境里的常见坑怎么排查。

1. 核心信息速览

先把这次融资事件和围绕企业 AI Agent 的关键信息放在一张表里。注意，表格中带“需确认”的内容，以 Telli 官方披露为准，不要直接写进招标方案或技术选型文档。

从融资消息看，Telli 拿到的钱主要用于扩充产品和市场团队，本质上还是“把企业 AI Agent 规模化交付”。对技术团队来说，这个新闻的真正价值是提醒我们：企业 Agent 不是“接一个大模型 API”就结束了，评测、部署、运维才是大头。

2. 企业 AI Agent 的适用场景与使用边界

2.1 能解决什么问题

企业 AI Agent 的核心价值，是把大模型的能力嵌入到真实业务流程中。适合优先落地的场景通常具备以下特征：流程重复、规则清晰、容错空间较大、人工复核成本可控。

典型场景包括：

• 客服工单自动分类和初答：Agent 读取工单内容，调用企业知识库，给出回复建议或直接回复标准问题。
• 内部知识库问答：让员工用自然语言查制度、查流程、查历史项目文档，Agent 负责检索并给出带来源的回答。
• 数据分析与报表生成：Agent 对接数据库或 BI 工具，将“本周各区域销售额对比”这类问题转成查询，再生成结论。
• 业务流程串联：例如合同初审、发票信息提取、招聘简历初筛，Agent 调用 OCR、结构化抽取和业务 API。
• 软件工程辅助：代码审查、单元测试生成、故障日志初步分析。

这类场景的共同点是：任务边界清晰，结果可以被人工快速复核。即使 Agent 偶尔出错，影响也在可控范围内。

2.2 不适合什么场景

企业 AI Agent 不是万能接口。以下场景建议慎重：

• 高风险自动化决策。例如自动解雇员工、自动拒绝贷款、自动修改核心财务数据，这类场景一旦出错代价极高，不应该让 Agent 直接执行。
• 缺乏人工复核通道的合规敏感场景。涉及法律意见、医疗诊断、金融投资建议时，Agent 输出只能作为辅助材料，不能作为最终结论。
• 涉及人脸、声音、个人敏感信息的大规模处理。如果要做人脸比对、声音克隆、个人信息画像，必须先确认数据来源合法、处理方式获得明确授权。
• 版权归属不明确的素材生成或处理。不能拿未经授权的图片、音频、视频直接投入商业生产。

2.3 使用边界与合规要求

从安全角度看，企业部署 AI Agent 至少要确认三件事：

1. 数据来源合规。喂给 Agent 的文档、图片、音频是否来自合法渠道，是否包含需要脱敏的个人信息。
2. 输出内容可控。Agent 生成的内容如果对外发布，是否有审核机制。
3. 访问权限收敛。Agent 能调用的系统、能读取的数据，必须遵循最小权限原则，不能给一个 Agent 开全库权限。

涉及本地部署、模型下载或者第三方 API 调用时，要确认模型授权范围。有些模型允许商用，有些只有研究许可，部署前先看 license。

3. Agent 落地为什么先看评测——Evals 是核心问题

3.1 传统 QA 测试为什么不够

很多团队第一次把 Agent 接到业务系统后，第一反应是“感觉还行”，真要上线又不敢。原因很简单：传统软件测试有明确断言，输入 A 应该得到 B；但 Agent 的输出是自然语言，同一个问题可能每次回答都不一样。

传统测试方法在 Agent 场景下会失效：

• 没有固定输出结构，不能简单地做字符串匹配。
• 同一个任务有多种可行路径，Agent 可能换一种工具调用顺序，但结果仍然正确。
• 回归测试成本高，模型更新或 Prompt 调整后，原来通过的用例可能开始失败。
• 只测“模型回答得好不好”，没测“Agent 能不能完成整个任务”。

这就是为什么最近业界反复讨论 demystifying evals for AI agents 的原因。Agent 评测并不是一个可有可无的环节，它直接决定了系统能不能从 Demo 走向生产。

3.2 Agent 评测核心维度

设计企业 Agent 评测时，建议至少覆盖以下指标：

评测不是“上线前做一次就结束”，而是应该沉淀成一套可持续运行的回归测试集。每次修改 Prompt、更换模型、调整工具定义之后，都跑一遍评测，对比指标变化。

4. 一套可落地的 Agent 评测流程

4.1 建立企业任务集

评测的第一步，是从真实业务里抽取任务。建议准备三类任务：

• 正常任务：业务中最常见的请求，覆盖典型场景。
• 边界任务：输入信息不完整、含义模糊、需要追问澄清的任务。
• 异常任务：工具接口报错、数据库无数据、用户请求超出权限范围。

先收集 30 到 100 个真实任务，按业务优先级排序，优先覆盖高频场景。任务集建议用 JSON 管理，方便版本化。

下面是一个任务集示例：

{ "id": "task_001", "name": "查询本周客户工单处理率", "description": "Agent 需要调用数据分析工具和 CRM 接口，返回本周工单处理率", "tools_available": ["BI_QUERY", "CRM_READ"], "check_fields": ["answer", "tool_call"], "expected": { "goal": "返回本周工单处理率，单位百分比", "range": "0-100 之间" } }

4.2 编写评测脚本

拿到任务集后，写一个最简单的评测脚本。核心逻辑是：把任务逐个提交给 Agent 服务，采集结果，再按规则判断成功或失败。

# agent_eval.py # 通用 Agent 评测脚本骨架，实际接口地址和鉴权方式按项目配置调整 import json import time import statistics import requests API_URL = "http://127.0.0.1:8000/agent/run" HEADERS = {"Authorization": "Bearer YOUR_TOKEN"} RESULTS = [] def run_agent_task(task: dict) -> dict: """调用 Agent 服务执行单个任务""" resp = requests.post(API_URL, json=task, headers=HEADERS, timeout=180) resp.raise_for_status() return resp.json() def evaluate_task(task: dict, result: dict) -> dict: """ 按规则评估结果。 这里用最简方案：completed 为 True 且关键字段存在就算成功。 真实项目建议引入 LLM-as-Judge 或人工复核。 """ success = bool(result.get("completed")) check_fields = task.get("check_fields", ["answer"]) for field in check_fields: if not result.get(field): success = False break return { "task_id": task["id"], "success": success, "latency_ms": result.get("latency_ms", 0), "cost": result.get("cost", 0), "steps": result.get("steps", 0), "error": result.get("error", ""), } def main(): with open("eval_tasks.json", "r", encoding="utf-8") as f: tasks = json.load(f) for task in tasks: start = time.time() try: result = run_agent_task(task) result["latency_ms"] = (time.time() - start) * 1000 RESULTS.append(evaluate_task(task, result)) except Exception as exc: RESULTS.append({ "task_id": task["id"], "success": False, "error": str(exc), }) success_rate = statistics.mean([r["success"] for r in RESULTS]) if RESULTS else 0 avg_latency = statistics.mean([r.get("latency_ms", 0) for r in RESULTS]) if RESULTS else 0 print(json.dumps({ "total": len(RESULTS), "success_rate": round(success_rate, 4), "avg_latency_ms": round(avg_latency, 2), "results": RESULTS, }, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()

注意，这个脚本是“最小可用版本”，只适合快速验证。企业环境里，还要把评测结果写回数据库、对比多版本 Prompt 的指标变化、通知相关人员。

4.3 引入 LLM-as-Judge 做质量评估

很多任务是无法用“字段是否存在”来衡量的。比如“回答是否准确”“语气是否专业”“是否准确引用了知识库内容”。这时候可以用一个大模型当评委，读取 Agent 的输出和参考答案，给出评分和理由。

# judge_example.py # 用大模型评估 Agent 回答质量，实际模型和接口按项目配置 from openai import OpenAI client = OpenAI(base_url="YOUR_MODEL_API_BASE", api_key="YOUR_API_KEY") judge_prompt = """ 你是企业 AI Agent 质量评审员。请基于以下标准评估 Agent 回答： 1. 信息是否完整，是否覆盖用户问题核心 2. 是否与提供的知识库材料一致 3. 是否存在明显幻觉或编造事实 4. 表达是否清晰、专业 输出 JSON 格式：{"score": 0-10, "reason": "简要说明扣分原因"} """ def judge_answer(question: str, agent_answer: str, reference: str) -> str: response = client.chat.completions.create( model="YOUR_JUDGE_MODEL", messages=[ {"role": "system", "content": judge_prompt}, {"role": "user", "content": f"问题：{question}\nAgent 回答：{agent_answer}\n参考资料：{reference}"}, ], temperature=0, response_format={"type": "json_object"}, ) return response.choices[0].message.content

LLM-as-Judge 不是银弹。遇到专业领域很强的任务，建议保留人工抽检机制，比如每批评测抽取 20% 由业务人员复核。

5. 企业部署架构与接口设计

5.1 系统分层

一套完整的企业 AI Agent 部署架构，通常包含六层：

• 接入层：Web UI、IM 机器人、API Gateway 对外提供访问入口。
• 编排层：负责拆解用户目标、规划执行步骤、调用工具、管理循环。
• 模型层：大模型推理服务，可以是云端 API，也可以是私有化部署的推理服务。
• 工具层：业务 API、数据库查询、知识库检索、OCR、邮件发送等外部能力。
• 记忆层：短期对话记忆、长期向量记忆、业务上下文存储。
• 安全层：身份认证、权限控制、审计日志、内容过滤。

这六层不是每个团队都必须一次性搭全。早期试点可以先简化成“API 入口 + 单个 Agent 服务 + 模型 API + 少量工具”。

5.2 API 接入示例

无论底层怎么实现，企业系统接入 Agent 最通用的方式就是 HTTP API。下面给一个最简单的调用示例。

curl -X POST "http://127.0.0.1:8000/agent/run" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -d '{ "task_id": "demo_001", "prompt": "查询本周客户工单完成情况", "tools": ["BI_QUERY", "CRM_READ"] }'

Python 调用方式类似：

import requests url = "http://127.0.0.1:8000/agent/run" payload = { "task_id": "demo_001", "prompt": "查询本周客户工单完成情况", "tools": ["BI_QUERY", "CRM_READ"] } headers = {"Authorization": "Bearer YOUR_TOKEN"} response = requests.post(url, json=payload, headers=headers, timeout=300) print(response.status_code) print(response.json())

这里的关键是超时设置。Agent 任务不是普通 API 请求，它可能要在内部调用多个工具，耗时几十秒甚至几分钟。客户端超时建议设置到 180 秒以上，或者干脆采用异步任务模式。

5.3 批量任务与异步队列

企业场景里，经常有“把这个 Excel 里的 500 条工单全部自动处理”的需求。这不是把 500 个请求同时发过去，而是要用任务队列控制并发，避免打爆模型接口和业务系统。

# batch_agent.py # 批量提交任务示例，建议生产环境用消息队列（Redis Queue / RabbitMQ）替代 import json import requests from pathlib import Path API_ENDPOINT = "http://127.0.0.1:8000/agent/run" HEADERS = {"Authorization": "Bearer YOUR_TOKEN"} BATCH_OUTPUT_DIR = Path("./batch_results") def submit_batch(file_path: str): BATCH_OUTPUT_DIR.mkdir(exist_ok=True) with open(file_path, "r", encoding="utf-8") as f: tasks = json.load(f) for task in tasks: try: resp = requests.post( API_ENDPOINT, json=task, headers=HEADERS, timeout=300 ) resp.raise_for_status() result = resp.json() print(f"task {task['id']} -> {result.get('status')}") # 将单条结果落盘，方便失败重跑 output_file = BATCH_OUTPUT_DIR / f"{task['id']}.json" output_file.write_text( json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8" ) except Exception as exc: print(f"task {task['id']} failed: {exc}") # 生产环境应写入失败队列，稍后重试 if __name__ == "__main__": submit_batch("batch_tasks.json")

批量任务设计时要注意四点：

• 幂等键。每条任务要有唯一 ID，重试时不会重复处理。
• 单条任务超时。不能因为一条任务卡死，拖垮整个队列。
• 失败重试。重试建议加退避策略，避免失败任务反复打同一个接口。
• 分目录输出。每个任务的输入、输出、日志单独落盘，方便定位。

6. 资源占用与性能观察

6.1 观察哪些指标

如果企业选择私有化部署，尤其是本地 GPU 推理，需要重点观察：

显存占用需要以实际模型版本和推理参数为准。不同模型、不同上下文长度、不同并发数，显存占用差异很大，不要照搬别人的数字，要在自己机器上实测。

6.2 如何降低资源占用

能落地的降本手段大概有几种：

• 模型量化。把 FP16 模型量化为 INT8 或 INT4，显存占用明显降低，精度损失需要评测集验证。
• 动态批处理。把多个请求合并成一个 batch 推理，提高 GPU 利用率。
• 上下文压缩。Agent 长任务会把历史消息越顶越长，可以把历史摘要化，只保留关键信息。
• 任务级缓存。相同或相似问题直接返回缓存结果，避免重复调用模型。
• 小模型分流。简单任务用轻量模型处理，复杂任务才调用大模型。

如果是云端 API 模式，资源占用主要变成成本指标，需要统计单任务平均 token 消耗，并设置每日调用上限。

7. 常见问题与排查方法

企业 Agent 上线后，问题通常集中在几个固定环节。下面这张表覆盖了最高频的故障。

排查的核心原则是：先看日志，再查配置，最后改代码。不要一上来就改 Prompt，先确认是模型问题、工具问题还是网络问题。

8. 企业级落地的最佳实践与合规红线

8.1 落地最佳实践

结合目前已经跑通的企业 AI Agent 项目，有几个经验可以复用：

第一，从最小可行场景切入。不要一开始就做“全能助手”，选一个边界清晰、数据干净、效益可量化的场景跑通闭环。比如“合同初审”比“公司战略咨询助手”更容易落地。

第二，评测集和业务场景同步建设。每次试点过程中发现的失败案例，都补充进评测集。评测集是一个持续增长的资产。

第三，设置人工复核节点。Agent 自动处理不是目的，降低人工成本才是。建议上线初期保留“Agent 处理后人工确认”的环节，积累足够的置信度后再扩大自动化范围。

第四，配置和 Prompt 全部版本化管理。Agent 的行为由 Prompt、工具定义、模型版本共同决定，任何一项变更都要记录，并触发回归评测。

第五，审计日志必须完整。谁在什么时候调用了 Agent，传入了什么数据，返回了什么内容，调用了哪些工具，全部记录。这既是排查问题的依据，也是合规审查的依据。

8.2 合规红线

涉及 AI Agent 的企业部署，以下红线不要踩：

• 未经授权处理个人信息。员工数据、客户数据、人脸、声纹等信息，必须先确认授权和合规依据。
• 使用版权不明的素材训练或生成内容。图片、音频、视频素材要确认授权范围。
• 让 Agent 直接执行不可逆的高风险操作。例如自动删除数据库记录、自动发送大量邮件、自动提交合同，必须加入人工确认。
• 敏感业务场景无人工复核。金融、医疗、法律等领域，Agent 输出只能作为辅助，不能直接作为最终决定。
• 忽略数据出境要求。如果使用境外模型服务，要确认企业数据是否允许传输到境外服务器。
• 对安全要求高的场景不做访问控制。Agent 能调用哪些工具、读取哪些数据，必须按最小权限配置。

这些不是空话。企业 Agent 一旦接入真实业务系统，出现一次合规事故，造成的损失远大于省下的那点人力成本。

9. 从融资新闻到工程实践的下一步

Telli 的融资是行业风向的一个切面。AI Agent 正在从“能跑通 Demo”进入“能不能稳定跑 1000 次”的阶段。对技术团队来说，下一步应该做的事很清楚：

第一，先建评测集。手工整理 50 个真实业务任务，标注出期望行为，跑一轮评测，拿到基线。

第二，做一次小范围试点。把 Agent 接到一个低风险、高频的业务场景里，用真实数据观察指标。

第三，沉淀部署和运维规范。API 怎么接入、批量任务怎么处理、失败怎么重试、日志怎么留，这些要在试点阶段就定好。

第四，再谈 Agent 智能化程度。基线稳定之后，再考虑多 Agent 协作、复杂工作流编排、长期记忆优化。

AI Agent 的资本热度还在，但工程侧的耐心更重要。评测先行、小步快跑、合规兜底，这条路线适合大多数想落地企业 Agent 的团队。建议把文章里的评测脚本、批量任务模板和排查表保存下来，试点的时候直接用。