一开始低估的事边界最早动手时我们对Bounded Context的理解停在概念层。会话Session、工具Tool、审计Audit都放在一个 service 里靠函数调用区分。第一个月运行没什么问题第二个月工具调用加了审批流程要改 Session 状态机同时改审计写入时机一次改动影响了三个方向回归测试全部要重跑。拆分到独立 BC 以后这个问题消失了。Tool BC 加审批逻辑改的是自己内部的状态机Session BC 只感知工具调用完成这一个事件不关心审批细节。代价是多了 gRPC 调用增加了几毫秒延迟但这个代价完全值得。结论BC 边界不是为了架构图好看是为了让每次改动的影响范围可控。边界划得晚比划错更痛苦。走了弯路Session 状态机Session 的状态设计我们反复改了几版。最纠结的一个问题是数据库里需要细粒度的状态来区分LLM 正在思考、“正在调工具”、等待人工审批这些不同阶段但如果把这些全塞进同一个状态枚举状态机的迁移规则会变得非常复杂——几十种组合改一处怕漏另一处。最终我们用了两级设计State 和 Phase。State状态是会话的生命周期一共 6 个idle会话已创建还没开始跑running正在执行 ReAct 循环paused暂停等 HITL 人工审批completed正常结束终态failed异常退出lastError记录原因终态cancelled用户或系统主动取消终态Phase阶段是running状态下的子阶段用来做 DB 持久化和 SSE 流事件对齐thinkingLLM 正在生成响应tool_use正在执行工具调用finalizing收尾整理最终回复这样做的好处是State 层面只需要管 6 个状态的合法迁移规则很简单——一张validTransitions转换表就够idle→running调Start()激活、cancelledrunning→pausedHITL 中断、completed、failed、cancelledpaused→running审批通过恢复、cancelledcompleted、failed、cancelled是终态不能再迁移任何不在表里的迁移代码直接返回ErrInvalidStateTransition错误不会静默通过。Phase 的推进则由SetPhase()方法驱动只在running状态下才生效其他状态调用是空操作。你可以把 State 想象成火车运行图上的大站始发、运行中、临时停车、到站、故障停运、取消Phase 是运行中的小站加速、减速、过桥。大站之间有严格的调度规则小站只是记录此刻在干什么。结论当状态粒度需求在不同层面不一样时用两级State Phase比把所有东西塞进一个枚举更清晰。状态机的价值不只是代码是让哪些迁移合法变成一张可审查的表。踩过的坑异步不代表可以忽略失败Memory 的记忆提炼是异步 fire-and-forget。上线初期日志里偶尔出现提炼失败我们当时觉得最多这次对话的内容没被记住不影响主流程就没处理。运行一段时间后发现失败率偏高原因是提炼用的 LLM 调用不够稳定。用户感知不到失败主流程没报错但记忆系统慢慢变薄——常用的偏好没被记住用户下次对话又要重新告知 Agent。虽然不是数据丢失但体验在悄悄变差。当前代码的做法是失败时保留事件不清空SaveTx事务保证事件不丢上层可以决定是否重试。同时持久层做了分层降级——优先走事务SaveTx聚合落库 事件写入同一事务事务失败则退到非事务路径Save Publish。这比最初失败就丢了强很多但完全自动化的重试如指数退避还在 roadmap 中。结论fire-and-forget 不是失败了算了是失败了不阻塞主流程但要有自己的兜底。事件不丢是最低要求自动重试是进阶目标。没想到的问题HITL 超时HITL 上线时我们设了审批超时 5 分钟代码里是HITLTimeout 5 * time.Minute超时后自动拒绝由一个每 5 分钟跑一次的 CronJobhitl-timeout检查并处理过期中断。这个时间对人在电脑前等着的场景够用但对需要找领导确认的场景太短。而且超时后走的是RejectInterrupt路径decided_bysystem:hitl-timeout原始参数虽然保留了存在session_interrupts表的args里但用户需要从头重新发起请求。当前超时值是硬编码常量还没有做到按租户/工具风险等级可配置——这是 roadmap 中的改进项。这个问题不是纯技术问题是没有从用户的工作流角度思考超时设定。结论涉及人工操作的流程超时和重试的设计要从人的行为习惯出发不能只从系统稳定性考虑。值得的决定RLS 在数据库层做隔离多租户隔离最开始有两个方案争论应用层过滤每个查询手动加WHERE tenant_id ?vs 数据库 RLS。应用层方案实现简单但有个明显的风险新人写查询忘了加WHERE tenant_id数据就串了。RLS 在数据库层强制过滤代码忘了加条件数据库帮你加。代价是每个事务开头要SET LOCAL app.tenant_id多了一次数据库交互。上线以后做过两次代码 review发现有 3 个查询路径确实遗漏了应用层过滤——如果靠应用层方案这 3 个地方就是数据串的漏洞。RLS 兜住了。结论隔离应该是系统约束不是依赖开发者自律。多一次数据库交互的代价远低于一次数据泄露事故。值得的决定指标集中定义早期各 BC 各自注册指标名字不统一。有的叫agent_runs有的叫agent.runs.totalGrafana 面板对不上每次加新面板要先 grep 代码找实际的指标名。把所有指标集中到metrics.Metrics结构体命名约定强制deepflux.domain.measure一个文件能看到全平台所有指标。Grafana 面板配置按这个命名写再也不用翻代码。结论可观测性基础设施早期投入是值得的散乱的指标命名是技术债修复成本很高。总结做企业级 Agent 平台技术本身不是最难的部分。难的是在系统还很小的时候做出那些在系统变大以后才能体现价值的设计决定。BC 边界、状态机、RLS 隔离、集中指标——每一个在实现时都比快速能跑麻烦但后来都成了省心的地方。选 Eino 做 Agent 编排框架节省了大量 ReAct 循环的基础设施工作让我们可以把更多时间花在业务逻辑和运营能力上。这个选择目前看来是对的。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】