技术探索不是赶时髦，而是为业务扛住压力
去年双11前两周，我坐在深圳南山科技园某栋写字楼里，一边用 Vim 快速切屏查看日志，一边在心里默默问候产品经理全家。当时团队正在上线一个“智能推荐+AI对话”的新功能，美其名曰“Lovable 用户体验升级”，实际就是把一堆还没跑通的 AI Agent 逻辑硬塞进老系统里。结果呢？上线不到两小时，数据库连接池爆了，运营后台卡成 PPT，客服电话被打爆。
作为这家三线互联网公司的技术负责人（别笑，虽然公司在一线城市的夹缝里生存，但团队十几号人真刀真枪干过不少活），我深知：技术探索不是为了写 PPT 吹牛，而是要在真实业务场景下扛得住、跑得稳、修得快。
今天这篇，不讲大模型原理，也不吹什么 AGI 革命，就聊聊我们怎么在资源有限、人力紧张、deadline 压顶的情况下，把“技术探索”真正落地为“可维护、可运营、可持续”的实践。
Lovable 不是形容词，是运营指标
很多人听到 “Lovable” 第一反应是“用户爱用”。听起来很美好，但对我们这种靠续费和转化活着的 SaaS 团队来说，“Lovable” 必须能被量化、能被监控、能被运营。
比如我们做了一个 AI Agent 帮助客户自动填写表单。产品经理说：“用户一定会觉得超贴心！”
我说：“行，那你告诉我，‘贴心’怎么测？”
后来我们定义了几个核心指标：
- 任务完成率：Agent 是否成功帮用户填完？
- 人工接管率：多少次需要用户手动修正？
- 会话时长：用户是否愿意继续聊下去？
- NPS 变化：上线后净推荐值有没有涨？
这些数据直接对接运营看板。一旦某个 Agent 的人工接管率连续三天超过 30%，自动触发告警，团队必须当天复盘。这不是技术炫技，这是用运营反推技术迭代。
有个小插曲：有一次运维同事看到告警邮件标题写着“Lovable Agent 崩溃”，一脸懵地问我：“Lovable 是个服务名？”
我回他：“对，意思是‘再崩一次我就不可爱了’。”
AI Agent 别堆功能，先管好状态
我们最早用 LangChain + 自研调度器搞了一套多轮对话 Agent。初期 demo 确实惊艳——能查订单、能改配置、还能讲冷笑话。但一上生产环境，问题全来了：
- 上下文太长，token 超限
- 多个 Agent 并发调用，互相污染状态
- 没有统一日志格式，排查问题像考古
痛定思痛，我们做了三件事：
1. 强制状态隔离
每个用户会话生成唯一 session_id，所有中间状态（包括工具调用结果、意图识别缓存）都存到 Redis Hash 里，TTL 设为 30 分钟。这样即使 Agent 崩了，重启也能恢复上下文。
" 在 Vim 里快速跳转看这段 Redis schema
key: agent:session:{user_id}:{session_id}
field: intent_cache → JSON
field: tool_results → JSON array
field: last_active → timestamp
2. 工具调用标准化
所有外部 API 调用必须走统一网关，带 trace_id 和 caller 标识。网关层做熔断、限流、重试。别让一个烂接口拖垮整个对话流。
3. 日志结构化 + 关键路径埋点
我们用 Structured Logging，每条日志包含：
- session_id
- turn_id（第几轮对话）
- agent_action（think / call_tool / respond）
- latency_ms
- error_code（如果有）
这样运营同学可以直接用 Kibana 查：“昨天有多少用户在第三轮对话时因‘库存不足’退出？”
代码可读性，是留给接班人的救命稻草
作为 Vim 党，我可能有点偏执——但我觉得，代码写出来不是给机器看的，是给人看的。尤其是 AI 相关的代码，逻辑嵌套深、异步多、错误路径复杂，如果命名糊弄、注释缺失，三个月后连自己都看不懂。
举个真实例子：我们有个函数叫 handle_user_input，里面嵌套了五层 if-else，还夹杂着 async/await 和 try-catch。新来的实习生改了个小逻辑，结果把异常处理路径绕过去了，线上用户输入特殊字符直接 crash。
后来我们定了三条铁律：
- 函数不超过 30 行，超过就拆
- 所有异步操作必须显式命名，禁止匿名 lambda
- 关键分支必须有注释说明业务背景
比如现在我们会这样写：
async def route_user_intent(session: Session, text: str) -> Intent:
"""
根据用户输入识别意图。
注意：电商场景下，'取消' 可能指取消订单、取消订阅、取消预约，
需结合上下文判断。详见 PRD v2.3 第5节。
"""
if "cancel" in text.lower():
return await resolve_cancellation_type(session, text)
elif is_order_query(text):
return Intent.ORDER_STATUS
else:
return Intent.UNKNOWN
别小看这几句注释。上周五晚上十点，测试同学发现“取消会员”没走对路径，我直接搜 PRD v2.3，五分钟定位到是上下文缺失导致误判——要是没这注释，怕是要熬通宵。
书不能只买不读，但也不能乱读
说到学习，很多团队陷入两个极端：
- 要么疯狂买课囤书，书架堆满《AI Engineering》《Agent Systems in Practice》，结果吃灰
- 要么完全靠网上碎片文章，东拼西凑，基础不牢
我们的做法是：每月技术分享会，强制每人精读一本技术书的一章，并结合项目讲“我能怎么用”。
比如上个月，后端小李读了《Designing Data-Intensive Applications》第11章（关于批处理与流处理），立刻意识到我们 Agent 的日志分析可以用 Kafka + Flink 实时计算接管率，而不是每天凌晨跑笨重的 Hive 任务。
另一个例子：我翻《The Pragmatic Programmer》时，看到“Tracer Bullet”概念——用最小可行路径打通端到端流程，快速验证可行性。这直接启发我们在 AI Agent 开发中采用“对话骨架先行”策略：先让 Agent 能走通完整对话流程（哪怕全是 mock 数据），再逐步替换真实逻辑。比传统瀑布式开发快了至少一周。
吐槽一句：有些 AI 书籍写得太飘，动不动“重构人类认知范式”，看得我直摇头。我们更爱那种带代码示例、讲权衡取舍的实战派。
技术选型：别被 hype 带跑，先问“谁来兜底”
去年有段时间，团队有人提议上 AutoGen 或 CrewAI，说“社区火、文档全、Demo 酷”。我问了三个问题：
- 如果半夜报错，谁能修？
- 如果要定制调度逻辑，源码能不能改？
- 如果 QPS 突增十倍，性能瓶颈在哪？
结果发现：AutoGen 的异步支持还不成熟，CrewAI 的内存泄漏问题在 GitHub issue 里躺了三个月没人理。
最后我们选择基于 FastAPI + Celery + Redis 自研轻量调度层。虽然少了点“高级感”，但好处是：
- 所有代码在掌控中
- 运维熟悉这套栈
- 出问题能快速 hotfix
下面是我们评估框架时用的一个简易打分表：
| 维度 | AutoGen | CrewAI | 自研方案 |
|---|---|---|---|
| 学习成本 | 中 | 高 | 低 |
| 调试友好度 | 低 | 中 | 高 |
| 生产稳定性 | 未知 | 一般 | 高 |
| 定制灵活性 | 低 | 中 | 极高 |
| 团队熟悉度 | 无 | 无 | 高 |
| 综合推荐指数 | ★★☆ | ★★★ | ★★★★☆ |
有时候，“土办法”才是最靠谱的办法，尤其是在你没有 Google 级别的 SRE 团队时。
最后一点真心话
技术探索很容易陷入两种陷阱：
- 要么闭门造车，搞出一堆没人用的“玩具”
- 要么盲目跟风，把公司当实验田
我们现在的原则是：任何新技术引入，必须回答三个问题：
- 它解决了哪个具体的业务痛点？
- 运营能否通过数据验证效果？
- 如果明天全员休假，系统还能稳住吗？
AI Agent 确实酷，Lovable 体验也确实重要，但别忘了——我们不是在参加黑客马拉松，而是在支撑一家公司的日常运转。代码要能读，系统要能修，数据要能看，这才是技术人的本分。
上周上线的新版本，人工接管率降到了 12%，NPS 涨了 8 分。运营同学请我喝了杯喜茶，说“你们这次真的做到了 Lovable”。
我笑了笑，回到工位，用 Vim 打开日志文件，继续优化下一个慢查询。
毕竟，在深圳这座卷到飞起的城市里，真正的技术浪漫，是让系统在凌晨三点依然安稳运行。
评论 0