QCon AI New York 2026 已确认 23 场议题，覆盖智能体授权、生产环境护栏、共享推理基础设施，以及 AI 系统上线后的评测。这几个方向看似分散，实际上指向同一个变化：团队关注的重点正在从“模型能不能回答”，转向“整个 AI 系统能不能被安全、稳定、可审计地运行”。
一个可以调用工具的智能体，不再只是聊天界面。它可能读取客户资料、执行退款、修改工单，甚至触发云端任务。因此，模型质量只是生产系统的一部分；权限边界、推理资源隔离、运行时控制和持续评测必须共同设计。
智能体授权不能等同于用户登录
传统应用常在入口完成身份验证，然后默认后续代码可信。智能体却会根据自然语言和模型输出动态选择工具，调用链可能是：
用户请求 → 智能体规划 → 检索上下文 → 选择工具 → 执行业务操作
这里至少存在三种身份：
- 发起请求的用户；
- 代表用户行动的智能体；
- 实际执行操作的工具或后端服务。
如果只检查“用户是否已经登录”，就可能让智能体获得超出本次任务的权限。更稳妥的做法是在每次工具调用时，根据主体、动作、资源和上下文重新授权。例如，客服智能体可以读取当前租户的订单，却不能读取其他租户数据；它可以生成退款建议，但超过一定金额时必须由人工批准。
授权层最好位于模型与工具之间，而不是写进提示词。提示词中的“不要访问其他客户数据”属于行为指导，并不是安全边界。真正的边界应由确定性代码、策略引擎和后端权限检查共同执行。
建议每次工具调用至少记录以下信息：
- 用户、智能体和服务身份；
- 请求的动作与资源；
- 授权策略版本及判定结果；
- 模型提出的参数和最终执行参数；
- 审批人、调用结果与关联 trace ID。
护栏与共享推理平台需要分层设计
生产护栏不是一条正则表达式，也不应只依赖另一个模型进行判断。实用的架构通常包含多层控制：
- 输入层：限制请求大小，识别敏感信息，检测明显的提示注入模式。
- 上下文层：只检索当前身份允许访问的文档，并保留来源信息。
- 模型层：限制可用模型、采样参数、最大 token 数和结构化输出格式。
- 工具层：校验参数、执行授权、设置超时，并为高风险操作增加审批。
- 输出层：检查敏感数据、引用完整性和业务规则，必要时降级或拒答。
共享推理基础设施会进一步放大这些问题。当多个团队共用模型网关、GPU 集群或缓存时，平台需要处理租户隔离、配额、成本归属、模型版本和突发流量。一个低优先级的批处理评测任务，不应挤占面向用户的在线推理；缓存键也不能因为缺少租户维度而造成数据串用。
可以把共享推理网关看成 AI 平台的控制面。它至少应提供：
- 按租户和应用设置限流与预算；
- 明确模型别名对应的实际版本；
- 记录延迟、token、错误和成本；
- 支持熔断、重试及备用模型；
- 区分在线请求、后台任务和离线评测的优先级；
- 对日志中的提示词和个人数据执行脱敏与保留策略。
上线后的评测必须连接真实运行数据
离线基准可以回答“这个版本在固定数据集上表现如何”，却无法完整回答“系统上线后是否仍然有效”。生产环境会不断引入新问题：用户表达发生变化，知识库内容过期，工具接口升级，模型供应商调整版本，攻击者也会探索新的绕过方式。
因此，评测应成为发布和运行流程，而不是上线前的一次考试。可以同时观察四类指标：
| 维度 | 示例指标 |
|---|---|
| 任务效果 | 问题解决率、人工接管率、工具调用成功率 |
| 安全与合规 | 越权调用数、敏感数据泄露率、护栏拦截率 |
| 系统性能 | 首 token 延迟、总延迟、超时率、可用性 |
| 资源成本 | 单次请求 token、模型成本、缓存命中率 |
聚合平均值往往会掩盖问题。评测结果应按租户、语言、任务类型、模型版本和工具版本切片。例如，总体成功率保持不变，并不代表新的模型没有让小语种请求明显退化。
LLM 评审器可以扩大评测覆盖面，但不宜充当唯一裁判。它可能受到提示措辞、自身模型版本和位置偏差影响。高风险场景仍需要确定性规则、人工抽检和业务结果指标进行校准。
一个可运行的最小闭环
下面是一个仅依赖 Python 标准库的示例。它演示了三件事：在工具调用前执行授权、把决策写入审计日志，以及在执行后生成可聚合的评测记录。
这是简化的实践样例，不代表会议披露了特定 API。保存为 agent_control.py 后即可运行：
from dataclasses import asdict, dataclass
from datetime import datetime, timezone
import json
import uuid
@dataclass
class Request:
user_id: str
tenant_id: str
action: str
resource_tenant: str
amount: float = 0.0
def authorize(req: Request) -> tuple[bool, str]:
if req.tenant_id != req.resource_tenant:
return False, "cross_tenant_access"
if req.action == "refund" and req.amount > 100:
return False, "human_approval_required"
if req.action not in {"read_order", "refund"}:
return False, "action_not_allowed"
return True, "allowed"
def execute(req: Request) -> dict:
if req.action == "read_order":
return {"ok": True, "result": "order_found"}
if req.action == "refund":
return {"ok": True, "result": "refund_submitted"}
return {"ok": False, "result": "unsupported_action"}
def handle(req: Request) -> dict:
trace_id = str(uuid.uuid4())
allowed, reason = authorize(req)
result = execute(req) if allowed else {"ok": False, "result": "blocked"}
event = {
"timestamp": datetime.now(timezone.utc).isoformat(),
"trace_id": trace_id,
"policy_version": "2026-01",
"request": asdict(req),
"authorization": {"allowed": allowed, "reason": reason},
"result": result,
"evaluation": {
"policy_compliant": allowed or result["result"] == "blocked",
"tool_success": bool(result["ok"]),
},
}
print(json.dumps(event, ensure_ascii=False))
return event
if __name__ == "__main__":
requests = [
Request("u-1", "tenant-a", "read_order", "tenant-a"),
Request("u-2", "tenant-a", "refund", "tenant-a", 150),
Request("u-3", "tenant-a", "read_order", "tenant-b"),
]
for request in requests:
handle(request)
运行命令：
python agent_control.py | tee agent-events.jsonl
在真实系统中，可以把 authorize 替换为独立策略服务，把事件发送到日志或流处理平台，并将人工反馈、退款是否最终成功等业务结果异步关联到同一个 trace_id。这样，团队不仅能统计模型输出是否流畅，还能回答更关键的问题：越权请求是否被阻止、工具是否正确执行、用户任务是否真正完成。
落地时从控制点而不是模型榜单开始
这 23 场议题所覆盖的方向提醒团队：AI 生产化是一项系统工程。选型时不应只比较模型分数，还要检查整个调用链是否可控。
上线前可以使用以下清单：
- 每次工具调用是否执行服务端授权，而非依赖提示词？
- 是否使用短期、最小权限的凭证，并禁止模型直接接触长期密钥？
- 高风险操作是否支持人工审批、幂等和撤销？
- 模型、提示词、策略、知识库与工具版本是否进入 trace？
- 在线流量与离线评测是否有独立配额和优先级？
- 是否同时监控质量、安全、延迟和成本？
- 指标是否能按租户、语言、任务和版本切片？
- 自动评审是否经过人工样本和业务结果校准？
真正成熟的 AI 平台，不是从不犯错，而是能够限制错误的影响范围，保留足够证据定位原因，并通过持续评测发现退化。智能体授权、运行时护栏、共享推理基础设施和上线后评测，正是构成这一闭环的四个关键部分。