大模型、Agent、AI Coding、具身智能接连进入工程视野，架构师面对的难题已经不只是“要不要采用 AI”，而是如何在变化速度、业务价值与系统风险之间做出可解释的选择。2026 腾讯云粤港澳大湾区架构师峰会所回应的，正是这种普遍的不确定感：技术人需要跟上浪潮，也需要知道自己为什么出发、系统最终要驶向哪里。
技术栈在变，架构责任没有变
每一轮新技术都会带来一批新名词，但生产系统关心的问题仍然具体：请求能否稳定完成，数据是否越权泄露，失败后能否回退，成本是否可以预测，团队能否持续维护。
以 Agent 为例，演示环境通常强调它能调用多少工具、完成多长的任务链；到了生产环境，架构师还必须回答：
- 模型输出不稳定时，哪些操作必须经过确定性校验？
- Agent 调错接口或重复执行时，如何限制影响范围？
- 提示词、模型和知识库升级后，怎样判断效果变好还是变坏？
- 推理成本突然上涨时，能否降级到规则、缓存或更小的模型？
- 用户数据进入模型上下文之前，在哪里完成脱敏和权限过滤？
这意味着 AI 架构不是在现有系统旁边增加一个模型接口。它需要把概率性组件装进一套可观测、可审计、可回滚的工程边界中。
不按热度选型，要按证据推进
面对快速变化的技术，团队容易落入两个极端：一种是看到新能力便立即重写系统，另一种是因为风险未知而拒绝试验。更稳妥的办法是给技术引入设置分级门槛。
可以把候选技术放入四个阶段：
| 阶段 | 目标 | 必须回答的问题 |
|---|---|---|
| 观察 | 理解能力边界 | 它解决了什么既有方案解决不好的问题？ |
| 试验 | 用真实样本验证 | 准确率、延迟和单次成本分别是多少？ |
| 受控上线 | 限制生产影响 | 是否具备灰度、审计、限流和人工接管？ |
| 规模化 | 建立长期能力 | 团队能否维护，供应商或模型能否替换？ |
这里最重要的变化，是把“这个技术看起来很强”改写为可测量的假设。例如，与其说“Agent 可以提高客服效率”，不如定义：在不降低答案合规率的前提下，把人工平均处理时长降低 20%，并把每次会话的模型成本控制在既定预算内。
可以这样实践：建立一个可执行的 AI 技术雷达
下面是一个独立的最小示例，并非峰会官方工具。它只使用 Python 标准库，根据业务价值、技术成熟度、可观测性、团队准备度和风险计算候选方案得分。团队可以替换权重和门槛，让评审依据进入版本库，而不是停留在会议纪要中。
将以下内容保存为 tech_radar.py，使用 Python 3.10 及以上版本运行：
from dataclasses import dataclass
@dataclass(frozen=True)
class Candidate:
name: str
business_value: int
maturity: int
observability: int
team_readiness: int
risk: int
def score(self) -> float:
return round(
self.business_value * 0.30
+ self.maturity * 0.20
+ self.observability * 0.20
+ self.team_readiness * 0.15
+ (10 - self.risk) * 0.15,
2,
)
def decision(self) -> str:
score = self.score()
if self.risk >= 8 or self.observability <= 3:
return "观察：先补齐风险控制和可观测性"
if score >= 7.5:
return "受控上线：设置灰度、预算和回滚条件"
if score >= 5.5:
return "试验：使用真实样本开展限时验证"
return "暂缓：当前收益不足以覆盖引入成本"
candidates = [
Candidate("代码审查助手", 8, 7, 8, 7, 4),
Candidate("自主生产运维 Agent", 9, 4, 3, 4, 9),
Candidate("内部知识问答", 7, 8, 7, 8, 5),
]
for item in sorted(candidates, key=Candidate.score, reverse=True):
print(f"{item.name}: {item.score():.2f} - {item.decision()}")
运行命令：
python3 tech_radar.py
这段代码不是为了制造一个绝对正确的总分。它的价值在于暴露分歧：业务部门可能给价值打 9 分，安全团队可能把风险评为 9 分，平台团队则指出当前无法追踪工具调用。评审会因此讨论真实约束，而不是围绕产品演示争论。
进入 PoC 后，还应为每项技术补充一份退出条件。例如：
experiment:
name: internal-knowledge-agent
duration_days: 21
success_criteria:
grounded_answer_rate: ">= 0.90"
p95_latency_ms: "<= 2500"
cost_per_session_usd: "<= 0.08"
guardrails:
require_source_citation: true
allow_write_actions: false
redact_personal_data: true
rollback_when:
compliance_incidents: "> 0"
daily_budget_usd: "> 100"
指标数值需要根据组织的业务基线调整。关键是同时写清成功标准、权限边界和停止条件，避免 PoC 因为“效果似乎不错”而无限延长。
架构师要保留三种能力
技术潮水持续变化时，架构师不必预测每个模型和框架的胜负，但需要保留三种稳定能力。
一是识别问题。先确认瓶颈来自知识检索、流程协同、代码生产还是物理执行，再决定是否需要大模型或 Agent。二是设计边界。把身份、数据、预算、工具权限、审计记录和人工接管做成系统能力。三是积累证据。用固定数据集、线上指标和故障记录验证改动，不用单次演示代替工程判断。
参加技术峰会也可以带着同一套检查表：这项能力解决什么生产问题，成功指标是什么，失败模式有哪些，谁承担长期维护成本，能否替换模型或供应商。这样，峰会带回来的不只是一串新名词，而是一组可以进入架构评审和工程迭代的判断依据。
在浪潮中保持自己的节奏
追新本身不是问题，没有目标地追新才会让团队疲惫。适合生产系统的节奏通常是：持续观察、小范围验证、带护栏上线、用数据决定是否扩大。对于高风险场景，还要保留人工确认和确定性流程，不能把“模型大概率正确”等同于系统承诺。
潮起潮落之后，真正留下来的往往不是最早使用某个名词的团队，而是能把新能力转化为可靠系统、清晰指标和可持续组织能力的团队。架构师的价值，也正在于为快速变化的技术建立这种稳定坐标。