Bluesight 的实践展示了一条典型但并不轻松的企业 AI 演进路径：团队没有停留在单一产品中的 AI 原型，而是借助两次 AWS 合作和 Amazon Bedrock AgentCore，将能力扩展为统一的智能体方案 Prism，覆盖六款医疗合规产品。面向 ControlCheck 的 Prism Assistant 已于 2026 年 5 月发布，并被 20 家医疗系统采用；更复杂的跨产品方案计划在 2026 年晚些时候推进。
这次演进值得关注的地方，不只是接入了大模型，而是如何把原型升级为能够跨产品运行、受权限约束并且可持续治理的产品能力。
单产品问答与跨产品智能体不是同一个问题
单产品原型通常只有一条短链路：接收问题、检索当前产品的数据、调用模型并返回答案。它可以快速验证模型是否理解业务术语，却很难直接复制到六款产品中。
跨产品智能体需要解决更多工程问题：
- 意图路由：判断请求属于哪个产品，或者是否需要组合多个产品的数据。
- 身份与权限传递：智能体能够调用工具，不代表当前用户有权访问工具背后的记录。
- 数据边界：医疗合规数据不能因为统一入口而失去产品、机构或租户隔离。
- 工具契约：不同产品需要以稳定、可验证的接口向智能体暴露能力。
- 审计与追踪：系统应记录模型调用了什么工具、使用了哪些参数，以及最终依据来自哪里。
因此，统一智能体不应被理解为一个可以访问所有数据库的聊天框。更稳妥的设计是：模型负责理解请求和编排步骤，确定性服务继续负责授权、查询、写入和合规校验。
AgentCore 的价值落在运行与治理层
根据来源摘要，Bluesight 使用 Amazon Bedrock AgentCore 推动 Prism 从原型走向统一方案。摘要没有披露具体组件拓扑，因此不能据此断言其内部采用了哪种路由器、记忆机制或数据存储。
不过，这类平台化工作的核心目标是明确的：把智能体从一次性的模型调用，提升为可以管理身份、工具、执行过程和观测数据的应用运行时。对于医疗合规场景，尤其要避免让模型承担它不擅长的职责。
可以把边界划分为三层：
- 模型层理解自然语言、选择工具并整理结果。
- 智能体运行层维护会话、执行工具调用、限制步骤数并生成追踪记录。
- 业务服务层实施最终授权、输入校验、租户隔离和事务控制。
即使模型选错工具，业务服务也必须拒绝越权请求。即使模型生成了看似合理的结论，界面也应区分“系统记录中的事实”和“模型归纳出的建议”。
可以这样实践：先定义受控的产品工具目录
下面是一个可改造的最小示例。它不代表 Bluesight 的实际实现，而是演示如何在接入 AgentCore 或其他智能体运行时之前，为多个产品建立显式工具契约。
先创建 tools.yaml。示例中的产品名和接口均为演示假设，运行前需要替换为实际服务地址：
products:
controlcheck:
tools:
- name: search_compliance_findings
description: Search compliance findings visible to the current user
method: GET
path: /v1/findings
allowed_parameters:
- health_system_id
- status
inventory:
tools:
- name: get_inventory_exception
description: Read one inventory exception visible to the current user
method: GET
path: /v1/exceptions/{exception_id}
allowed_parameters:
- exception_id
- health_system_id
接着可以用一个本地 Python 程序验证路由和权限边界。该示例只使用标准库，可以直接运行：
from dataclasses import dataclass
from typing import Callable
@dataclass(frozen=True)
class RequestContext:
user_id: str
health_system_id: str
allowed_products: frozenset[str]
Tool = Callable[[RequestContext, dict], dict]
def search_findings(ctx: RequestContext, args: dict) -> dict:
requested_tenant = args.get("health_system_id")
if requested_tenant != ctx.health_system_id:
raise PermissionError("Cross-tenant access denied")
return {
"items": [
{
"id": "finding-1042",
"status": args.get("status", "open"),
"source": "controlcheck",
}
]
}
TOOLS: dict[tuple[str, str], Tool] = {
("controlcheck", "search_compliance_findings"): search_findings,
}
def execute_tool(
ctx: RequestContext,
product: str,
tool_name: str,
arguments: dict,
) -> dict:
if product not in ctx.allowed_products:
raise PermissionError(f"Product access denied: {product}")
tool = TOOLS.get((product, tool_name))
if tool is None:
raise ValueError(f"Unknown tool: {product}.{tool_name}")
result = tool(ctx, arguments)
return {
"audit": {
"user_id": ctx.user_id,
"product": product,
"tool": tool_name,
},
"result": result,
}
if __name__ == "__main__":
context = RequestContext(
user_id="user-17",
health_system_id="hs-20",
allowed_products=frozenset({"controlcheck"}),
)
output = execute_tool(
context,
product="controlcheck",
tool_name="search_compliance_findings",
arguments={"health_system_id": "hs-20", "status": "open"},
)
print(output)
运行命令：
python3 agent_tools.py
真正接入模型时，可以要求模型只输出结构化工具请求，例如：
{
"product": "controlcheck",
"tool": "search_compliance_findings",
"arguments": {
"health_system_id": "hs-20",
"status": "open"
}
}
运行时必须再次验证产品权限、参数集合和租户标识，不能因为这些字段来自模型就默认可信。模型提示词也不应包含数据库凭据或长期访问令牌。
从一个助手扩展到六款产品时要观察什么
ControlCheck 助手已经投入使用，而更复杂的多产品方案仍在推进，这种分阶段交付方式能把风险限制在可观察范围内。团队可以先验证高频任务是否真的缩短了操作时间，再决定哪些跨产品流程值得自动化。
上线指标不应只有回答次数。更有用的指标包括：
- 工具选择正确率与参数校验失败率；
- 用户接受、修改或放弃答案的比例；
- 每个任务的模型调用次数、延迟和成本；
- 越权访问被拦截的数量；
- 缺少依据、引用错误和人工升级的比例；
- 不同产品版本变更导致的工具契约失败。
采用建议：统一入口，保留确定性边界
Bluesight 的路线说明，企业智能体的难点会从“模型能否回答”迅速转向“系统能否跨产品可靠执行”。准备采用类似架构时，可以用下面的清单评审：
- 每项工具是否具有明确输入、输出、超时和幂等语义；
- 授权是否在业务服务端执行，而不是依赖提示词；
- 每次工具调用是否关联用户、租户、产品和追踪标识；
- 高风险写操作是否需要确认或人工审批；
- 模型不可用时，核心合规流程是否仍能运行；
- 是否能够按产品、租户或工具快速关闭智能体能力。
统一智能体可以减少用户在多个产品之间切换的成本，但它也扩大了错误路由和越权调用的影响范围。先把工具契约、授权和审计做成平台能力，再逐步增加跨产品编排，通常比直接追求一个无所不能的助手更可控。