当支持请求持续增长时，企业通常会遇到一个两难问题：一方面，希望用 AI Agent 自动处理重复咨询、系统查询和问题分流；另一方面，企业内部系统往往运行在本地数据中心，数据权限、审计要求和安全边界又不能被牺牲。
Mobileye 的实践聚焦于这个现实问题：从支持运营瓶颈出发，通过概念验证验证方案，再使用 Amazon Bedrock AgentCore 构建连接本地系统与 AWS 云服务的混合架构。这个过程对希望扩大 AI Agent 应用、同时保持企业级治理能力的团队具有参考价值。
从支持瓶颈开始，而不是从模型开始
支持团队的瓶颈通常不只是“回复速度慢”。更常见的情况包括：
- 支持人员需要在多个系统之间反复查找信息；
- 大量请求属于可标准化的查询、状态确认或故障排查；
- 高级工程师被低价值、重复性的工单占用；
- 复杂问题需要结合企业内部知识、实时系统状态和历史上下文才能判断。
在这种场景中，传统聊天机器人往往能力有限。它可以匹配 FAQ，却很难安全地调用内部系统，也无法根据查询结果决定下一步动作。Agentic 方案的价值在于，它可以把一个支持请求拆成多个步骤：理解意图、选择工具、查询数据、整理结果，并在需要人工判断时转交支持人员。
但这也带来了新的工程要求。Agent 不只是生成文本的组件，它可能访问敏感数据、调用具有副作用的 API，并影响工单处理流程。因此，架构设计必须同时考虑身份认证、工具授权、执行边界、日志审计和人工介入。
用概念验证验证真正的可行性
一个有效的 PoC 不应只展示“模型能否回答问题”，而应验证完整的支持闭环。例如，可以选取一类边界清晰、风险可控的请求，测试以下流程：
- 接收用户的自然语言请求；
- 判断请求类型和所需权限；
- 调用一个只读的企业内部工具；
- 将结构化结果转换成支持人员可以理解的答案；
- 对无法确认或风险较高的情况进行人工升级；
- 保留请求、工具调用和最终响应的审计信息。
下面是一个可运行的最小化示例。它模拟一个支持 Agent 调用“查询设备状态”的内部服务。这个示例不代表 Mobileye 的具体实现，而是展示在 PoC 阶段可以怎样划分 Agent 与企业工具之间的边界。
运行前需要 Python 3.10 或更高版本：
from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
from typing import Optional
import uvicorn
app = FastAPI(title="Support Tool Gateway")
DEVICES = {
"device-1001": {"status": "online", "firmware": "2.4.1"},
"device-1002": {"status": "offline", "firmware": "2.3.9"},
}
class DeviceQuery(BaseModel):
device_id: str
@app.post("/tools/device-status")
def device_status(
query: DeviceQuery,
x_agent_token: Optional[str] = Header(default=None),
):
# 生产环境应替换为企业身份系统和细粒度授权策略。
if x_agent_token != "poc-readonly-token":
raise HTTPException(status_code=403, detail="tool access denied")
device = DEVICES.get(query.device_id)
if device is None:
raise HTTPException(status_code=404, detail="device not found")
return {
"device_id": query.device_id,
"data": device,
"access_mode": "read-only",
}
if __name__ == "__main__":
uvicorn.run(app, host="127.0.0.1", port=8080)
启动服务：
python support_tool_gateway.py
发送测试请求：
curl -X POST http://127.0.0.1:8080/tools/device-status \
-H 'Content-Type: application/json' \
-H 'X-Agent-Token: poc-readonly-token' \
-d '{"device_id":"device-1001"}'
在真实系统中，Agent 不应直接获得本地数据库凭据。更稳妥的做法是通过受控的工具网关暴露有限能力，例如只读查询、字段过滤、参数校验和请求审计。这样既可以让 Agent 获得完成任务所需的信息，也能降低模型误用工具的影响范围。
混合架构的关键：把本地系统能力封装成受控工具
Mobileye 案例的核心价值之一，是展示了本地系统与 AWS 云服务之间的连接思路。企业通常不可能一次性迁移所有支持系统，因此 Agent 需要在云端运行推理和编排能力，同时安全访问仍位于本地的数据和服务。
可以将架构拆成几层：
- 交互层：接收支持人员或客户的请求，并返回答案或升级结果；
- Agent 编排层：负责意图识别、步骤规划、工具选择和结果整合；
- 工具网关层：向 Agent 暴露稳定、有限、可审计的 API；
- 企业系统层：包含本地工单、设备、知识库或其他运营系统；
- 治理与观测层：记录身份、提示词、工具调用、响应和人工介入事件。
Amazon Bedrock AgentCore 可以作为云端 Agent 运行环境和企业集成架构的一部分。具体服务划分需要根据组织的网络、身份和数据要求设计，但基本原则是稳定的：模型负责推理，工具负责访问企业能力，权限系统负责决定 Agent 能做什么。
一个抽象的工具配置可以写成这样：
agent:
name: support-assistant
model_provider: amazon-bedrock
max_steps: 6
require_human_approval_for:
- update_ticket
- change_device_configuration
network:
tool_gateway: private
enterprise_connection: hybrid
allow_outbound_domains:
- internal-support.example
tools:
- name: get_device_status
endpoint: https://internal-support.example/tools/device-status
method: POST
permission: support.device.read
side_effects: false
audit: required
- name: create_ticket
endpoint: https://internal-support.example/tools/tickets
method: POST
permission: support.ticket.create
side_effects: true
human_approval: required
这里的配置是实践示例，不是 Amazon Bedrock AgentCore 的固定配置格式。它强调的是设计意图：只读工具可以在明确授权后自动执行；创建工单、修改设备配置等具有副作用的操作，则应增加审批、幂等性和回滚策略。
企业级 Agent 必须具备的控制面
扩大 Agent 使用范围时，最容易被忽略的是控制面。一个看似简单的支持请求，可能涉及客户身份、设备信息、内部诊断数据或业务规则。建议至少建立以下控制：
身份与权限
Agent 的身份应与调用者身份关联，不能让所有用户共享一个全能服务账号。工具授权应尽可能细化到操作、资源和数据字段，并在网关侧再次校验，而不是只依赖模型遵守提示词。
数据最小化
工具返回的数据应只包含完成任务所需的字段。对于支持回答来说，模型可能只需要设备状态和固件版本，不需要完整日志、用户隐私字段或内部凭据。
工具调用审计
审计日志应记录谁发起了请求、Agent 选择了哪个工具、使用了哪些参数、工具返回了什么结果，以及最终是否由人工确认。对于排障和合规调查而言，这些记录比单纯保存最终答案更有价值。
人工升级
当请求超出知识范围、需要修改生产状态、涉及敏感数据，或 Agent 多次无法完成任务时，应转交人工。人工升级不是 Agent 失败的标志，而是企业级自动化必须保留的安全边界。
评估与回归测试
PoC 成功后，团队还需要建立可重复的评估集，覆盖正常问题、模糊问题、越权请求、工具异常和恶意输入。每次更换模型、提示词或工具接口，都应重新验证答案质量和权限行为。
适合采用的落地路径
企业可以按以下顺序推进：
- 选择一类高频、低风险、边界清晰的支持请求；
- 先开放只读工具，验证数据访问和回答质量；
- 将本地系统能力封装为版本化 API，而不是让 Agent 直接连接数据库；
- 为每个工具定义权限、数据范围、超时、重试和审计要求；
- 对有副作用的操作增加人工审批和幂等设计；
- 通过线上指标评估解决率、人工升级率、工具错误率和响应延迟；
- 在稳定后再扩展到更多系统和更复杂的工作流。
这条路径的重点不是追求一个“无所不能”的 Agent，而是把自动化能力限制在可解释、可审计、可回退的范围内。Mobileye 的案例说明，企业 AI 支持系统的挑战同时存在于模型、系统集成和治理三个层面。只有将这三者一起设计，Agent 才能从概念验证走向可靠的生产运营。
结语：先定义边界，再扩大能力
Amazon Bedrock AgentCore 为企业构建和运行 AI Agent 提供了云端基础，但真正决定项目能否落地的，仍是企业内部系统的连接方式和治理设计。
对于正在评估类似方案的团队，可以用四个问题检查准备情况：
- Agent 首批要解决的具体支持瓶颈是什么？
- 它需要访问哪些系统，哪些数据绝对不能暴露？
- 哪些工具调用可以自动执行，哪些必须人工批准？
- 出现错误时，是否能够定位、撤销并解释 Agent 的行为？
先用小范围、只读、可审计的工作流验证价值，再逐步扩大工具和操作权限，通常比一次性构建全能 Agent 更容易达到企业级可靠性。