企业官网建设流程全解析

企业 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 类产品时，通常最关心四个问题：

这些问题不是靠把 Prompt 写长就能解决的，它们对应的是 Agent 架构设计、评测体系、日志链路和权限模型。换句话说，融资解决的是商业问题，但交付 Agent 前，工程团队必须先解决可靠性问题。

2. 企业 AI Agent 到底由哪些模块组成

2.1 从一条用户请求看 Agent 的运行链路

为了让问题具体化，假设企业内部有一个“售后工单处理 Agent”。用户提交一条工单：“客户反馈商品颜色发错，要求补发正确颜色，并补偿一张优惠券。”

Agent 要完成这个任务，内部大概会经历下面几个环节：

1. 任务理解：解析用户意图，识别出需要“补发”和“发优惠券”两个动作；
2. 信息收集：调用订单查询工具，确认订单号、商品 SKU、收货地址；
3. 工具调用：调用补发接口创建换货单，再调用优惠券接口发放券码；
4. 结果校验：检查接口返回状态，确认两个动作都成功；
5. 结果输出：生成给用户的答复文案。

如果任何一个环节失败，例如订单查不到、补发接口超时、优惠券已发过，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 不是越聪明越好，而是越可控越好。

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 Agent

4.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 在生产环境一定会遇到接口超时、数据为空、模型输出格式异常等问题。不要假设一次执行会成功，建议内置重试机制：

1. 工具调用失败：区分可重试错误与不可重试错误；
2. 模型输出解析失败：要求模型重新输出，并附上前一次输出的错误原因；
3. 工具返回空结果：让模型判断是换关键词、查关联数据，还是直接说明找不到；
4. 达到最大步数：停止循环，保留上下文，转给人工处理。

一个有效的替代路径是“降级为普通对话助手”。当 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。实际推荐顺序是：

1. 先确认用户输入到达服务端，请求没有被网关、接口层截断；
2. 再确认 LLM 响应是否正常，是否出现超时、限流、内容审核拦截；
3. 然后检查模型决策输出是否被解析成功；
4. 接着检查工具层日志，确认工具是否真的被执行；
5. 最后看上下文里有没有遗漏关键信息。

下面这个表格可以当排查清单用：

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 工程化不是一次改造，而是一套持续叠加可信层的过程。