我记录技术点，也记录判断过程和试错过程。

高级开发：功能之外的系统边界

我对高级开发的理解是能处理更多上下文：历史系统、团队协作、上线风险、故障后果和长期维护成本。 在服务治理、配置抽象、跨域访问、发布控制器这些主题上，我通常先把数据流、状态流和失败路径画清楚，再讨论具体实现。

好的抽象应该减少系统的自由度，避免把底层复杂度换一个名字继续暴露出去。

稳定性与验证

我做方案时会尽量提前写清楚压测模型、核心指标、资源测算、灰度顺序、回滚开关和上线观察项。 例如发布最后阶段的副本数约束，需要明确最大副本上限、origin / canary 如何增减、非生产环境是否跳过流量修改。 这类细节看起来繁琐，但能避免系统在边界条件下突然失控。

源码与机制

我读源码通常为了解答具体问题：为什么行为和预期不一致，哪个层面决定了结果。 例如 gRPC 双向流里，send 成功并不代表上游链路一定可用；Envoy 作为七层代理，上游错误可能要到 recv 才返回。 NATS 客户端重连时会切 pending buffer、重发订阅、再 flush 待发送消息。理解这些机制，排障时才能越过表面现象。

AI Agent：进入真实工程流程

我对 AI Agent 的兴趣来自两个方向：一是把日常工程经验变成智能辅助能力，例如治理配置推荐、告警分析和问题初筛； 二是把个人研发流程做得更高效，例如用 Codex、skill、sub-agent 和脚本组合完成资料整理、代码修改、交叉检查和文档生成。

我也踩过坑：试过自动化内容处理、个人 Agent、自动化编码协作平台。很多想法一开始看起来很顺，跑起来会遇到抓取不稳定、模型输出漂移、 产品定位不清、没有验收闭环等问题。后来我的判断变得更务实：动态判断可以交给模型，稳定步骤尽量用代码；多 Agent 的核心仍是上下文管理、工具边界和反馈循环。

所以我关注 AI Agent 偏工程落地的部分：工具设计、任务编排、评测集、失败归因、人工接管、日志与可观测。

表达边界

调研、设计、压测、源码分析和落地成果需要分开描述，AI 试错也一样。 我做过方案设计、技术选型、问题定位、压测验证、控制器流程设计、源码分析、治理能力抽象，也做过 AI Agent 和自动化工作流探索。 有些已经落地，有些停留在验证和复盘阶段；边界说清楚，内容就接近真实工程。

有分量的表达来自具体拆解：约束、路径、验证结果和下一步。