可靠客服 Agent 综合构建
停止孤立地调某一个组件。构建一个完整客服系统，让 Prompt、Context、Harness、Loop、Graph 与 Evaluation 的策略在同一组约束下保持一致。
只有当行为契约、知识供给、运行时控制、局部迭代、全局编排和评测证据都服从同一组约束时，一个生产 AI 架构才真正接近可发布。
参考架构只是这个教学场景下一种可以被辩护的配置，不是所有系统都应照抄的标准答案。
—
—
—
—
—
—
你要为整个系统辩护，而不是为某一个指标辩护
这个 Capstone 把推理单位从单个子系统提升到整个 AI 系统。一个局部上看似优秀的选择，和其他层发生冲突后可能变成糟糕架构。强 Retrieval 修复不了含糊的指令权限；安全 Prompt 也无法强制建立运行时权限边界；可靠 Loop 仍然可能被放进一个不必要复杂的 Graph；一个不错的候选版本也可能因为 Evaluation 证据薄弱而被错误发布。
Prompt Engineering 定义行为契约：哪些指令拥有更高权限、高后果约束怎样表达、检索到的内容是数据还是指令，以及下游系统需要怎样的输出结构才能校验。在这个挑战里，未解决的 Prompt 冲突属于明确 blocker，而不是一个可以被平均掉的小质量扣分。
Context Engineering 同时包含 Retrieval 和工作上下文策略。Retrieval 决定哪些证据能够被找到；压缩和预算策略决定哪些证据最终能留在模型工作集里。架构既要保留足够的关键内容，也不能无限突破 Context Budget，更不能为不会改善任务的证据持续支付成本。
Harness 与 Loop Engineering 控制执行过程。校验、人工审批、重试、超时、终止和局部恢复会同时改变可靠性、运行成本与风险。增加重试可能提高完成率，也可能制造更多重复工作和长尾延迟，所以执行策略必须被当作一个生产控制系统，而不是只看单一成功率。
Graph Engineering 决定责任如何连接。Coordinator 带很多 Workers 看起来更高级，却可能增加状态耦合和失败传播。更小的分支工作流可以保留独立证据、只重试失败节点、在 Join 时校验，并把人工审核放到真正高后果的边界。只有当这些结构带来可测量优势时，Graph 的复杂度才值得存在。
Evaluation Engineering 把所有设计选择转换成发布决策。数据覆盖、证据区间、安全 veto 与成本 Gate 决定什么叫“准备好了”。同一个架构在偏 Demo 的 Evaluation 中可能看起来完全可以发布，换成生产 Gate 就会失败。因此 Evaluation 是系统架构的一部分，而不是上线前临时加上的 Dashboard。
这里所有数值都是由现有 AhaFrame Labs 组合出来的确定性教学抽象，不是真实模型 Benchmark，也不是通用生产阈值。目标是练习在显式约束下为一个完整架构给出可辩护理由，然后把这套推理带到拥有真实测量数据的生产系统。