Engineering Method

后端系统和 Agent，都需要可复盘的工程过程。

高级开发和 AI Agent 看起来是两个方向，底层要求很接近：边界要清楚，状态要可见，失败要能处理，结果要能验收。只是前者面对服务、网络和发布流程，后者面对模型、工具和上下文。

Step 1

定义问题边界

后端问题先分清容量、时延、可用性、交付效率或治理复杂度；Agent 问题先定位检索、推理、工具、上下文或验收环节。

Step 2

把网络条件、资源成本、兼容性、上线窗口、回滚要求、模型稳定性、工具权限和人工接管边界放在一起评估。

Step 3

比较方案时同时看功能、复杂度、维护成本、观测能力和失败时的可控性。Agent 方案需要走出 demo 场景再判断价值。

Step 4

后端用压测、日志、指标、火焰图和灰度观察；Agent 用样例集、人工评审、自动检查、失败归因和迭代记录。

Step 5

把一次问题处理沉淀成规范、平台能力、自动化流程、排查手册或可复用 skill，降低下一次类似问题的处理成本。

Case Patterns

当底层配置过于灵活时，直接暴露给业务团队会带来规则冲突和维护成本。稳妥的做法是定义上层语义模型，再由控制器映射到底层资源，并保留反向生成、比对、提交、回滚和灰度路径。

一个 Agent 能不能用，关键通常在工具稳定性、上下文质量、输出检查、失败定位和接管方式。动态判断交给模型，稳定流程交给代码和检查器。

线程数、连接分配、日志格式、采样率、CPU 限制都会影响延迟分布。优化前先明确测试模型和负载条件，优化后看 P50/P90/P99 与资源水位，单次峰值只能作为补充参考。

原地升级、镜像预热、连接排空和内部路由迁移，本质上都需要把“开始变更”和“允许继续”拆开。每个阶段都应该有明确状态、超时、重试、回滚和观测指标。

我做过一些自动化内容处理和编码工作流探索，结论并不全是成功经验。最大的教训是：缺少验收标准和反馈循环时，几千行代码或一套复杂工作流也可能只停留在演示层面。