循环、记忆、工具调度、安全策略这些核心控制流不能插件化，一个坏插件能让 Agent 无限循环或越权。适合插件的是：具体工具（查天气、读文档）、输出格式化、特定领域的反思/评分逻辑、UI 渲染。判断标准：如果插件失败会影响整个 Agent 的可靠性和安全性，就放进核心；如果只是换一种做法，再交给插件。核心要稳，插件要轻。

不要每个模型写一套 SSE。抽象一层统一协议：统一请求体（模型、温度、max_tokens、消息数组）和统一响应事件（Start/Content/Finish/Error）。适配器负责把各家流式格式转成内部事件，OpenAI 的 data:、Anthropic 的 message_start/message_delta、Gemini 的 candidates 都能映射。业务层只消费标准化事件，换模型不用改业务代码。异步队列削峰，超时按模型动态配置。

HTAP 的坑不在 TP/AP 同时跑，而在于资源隔离、数据一致性和查询路由。TiDB 的 TiFlash 列存提供实时分析，但大 AP 可能抢 TP 的 IO 和网络；OceanBase 共享存储架构扩展好，但复杂查询优化器调优门槛高；平凯（原 PingCAP 企业版）重在金融强一致场景，部署和许可证成本是考虑点。通用经验：把 AP 流量限时限资源，避免直接查热表；复杂分析走离线导出或独立集群更稳。

一切皆插件是把能力拆成可插拔单元，按需组合，扩展快、风险隔离好。Capability Seam 是能力缝，也就是不同系统/模型/工具之间的能力边界和接口，插件在这里对接。特权核心必须有：安全策略、权限校验、审计、调度、资源配额这些不能交给插件，否则谁都可能越权。插件跑业务，核心管规则，分层不能乱。

卡脖子不是单点，是生态。设计可以靠先进IP和工具，但先进制程、EDA、先进封装、关键材料被锁；更麻烦的是软件生态，操作系统、编译器、开发者工具链、行业应用迁移成本极高。制造端的良率和产能爬坡也慢。所以突围顺序：先把成熟制程+特色应用（汽车、工控、AI推理）跑通，积累IP和生态，再攻先进制程。别指望一颗芯片翻身，得整条链。

得看存什么。6G如果是内存，对一些本地工具来说还行；1T硬盘对普通文档、表格、代码基本够用。但如果存视频、图纸、日志、备份，1T很快就满。更靠谱的做法是按实际用量估：先统计现有数据量，加上年增长，再乘以2到3倍保留余量。另外别忘了备份会占一份空间，快照、版本历史也要吃容量。直接问6G 1T够不够，不如先列清楚数据类型和增长预期。

就是把信息按需加载，而不是一次性全塞进上下文。系统先识别用户意图，再决定调用哪些skill或工具，无关模块不激活、不取数据、不占token。比如用户问财务问题，只加载财务相关技能；问代码问题，只触发工程模块。这样能省token，也减少模型被无关信息干扰导致的幻觉。实现上需要一个好路由层，能根据关键词、历史对话和任务类型动态匹配技能，否则该调用的没调出来，反而误事。

本质上是规模化采购加流量套利。中转站集中采购大量账号或企业套餐，拿到比个人开发者低的单价，再拆卖；有些会把请求路由到成本更低的区域或集群；还有的是做缓存复用，把常见问题结果存起来直接返回。但要注意，这种模式有隐患：账号可能被封、响应稳定性差、数据经过第三方有合规风险。如果项目对延迟和隐私敏感，建议直接走官方渠道；如果只是实验性质，中转站能省点钱。

还有下降空间，但边际收益会递减。看得见的路径：模型压缩、量化、蒸馏出小模型；推理侧做KV Cache复用、动态批处理、投机采样；基础设施用更密的算力和更优的调度。但真正的成本大头是业务侧的无脑调用，比如长上下文塞垃圾、反复重试、不分流复杂任务。接下来成本下降更多来自工程化，而不是单纯等模型降价。建议先把自己的调用链路审计一遍，别盯着厂商价格表。

不能一刀切。垂域模型在边界清晰、数据封闭的场景里确实更稳，比如医疗诊断、法律文书、工业质检，这些领域需要严格术语和可控输出。但代价是通用能力下降，换个场景就拉胯。通用大模型胜在迁移快、脑洞多，适合探索性任务。关键不在模型本身，而在于你有没有高质量领域数据做微调或RAG。数据质量不行，垂域模型照样胡说；数据做得好，通用模型加知识库也能打。选型时把准确率和成本放在一起看，别为了一点提升牺牲可维护性。