ZeroCoding

AI Agent 是当下大模型应用最热门的方向之一。本文从最基础的 ReAct 推理循环讲起，梳理单 Agent 的核心构成：模型、工具、记忆与规划。

从 ReAct 开始

ReAct（Reasoning + Acting）把「思考」和「行动」交替进行，让模型在推理的同时调用外部工具，从而突破纯文本生成的局限。

RAG（检索增强生成）是让大模型「有据可查」的关键手段。落地时，检索质量直接决定了生成效果的上限。

选型三件套

1. Embedding 模型：中文场景优先选对中文友好的模型，注意向量维度与语种覆盖。
2. 向量库：小规模用 pgvector 即可，规模上来再考虑 Milvus、Qdrant 等专用方案。
3. 召回策略：稠密召回为主，稀疏（BM25）做补充，混合检索通常效果更稳。

两个常被忽略的优化

• Chunk 切分：按语义边界切分，保留标题层级，比固定长度效果好很多。
• 重排序：用 Cross-Encoder 对召回结果二次排序，能明显提升 Top-K 的命中率。

提示工程是把大模型用好的基本功。这里整理几个在真实业务里反复验证有效的技巧。

三个核心原则

1. 给足上下文：把背景、角色、约束写清楚，别让模型猜。
2. 要求结构化输出：明确 JSON Schema 或 Markdown 格式，方便下游解析。
3. 分步引导：复杂任务拆成多步，配合思维链（CoT）让模型「想清楚再说」。

少样本示例

给 1～3 个高质量示例，比写一堆抽象规则更有效。示例要覆盖边界情况，让模型学会「什么时候该怎么做」。

幂等性是分布式系统的老问题，却是高并发场景下最容易踩坑的地方。核心诉求只有一个：同一个操作执行多次，结果和只执行一次一致。

常见落地手段

1. 数据库唯一约束：最可靠，通过唯一索引天然去重，适合「创建」类操作。
2. 状态机：把业务状态流转设计成幂等的，重复请求自然被挡在状态判断之外。
3. Token / 去重表：请求先拿 Token，消费一次即失效，适合「提交」类操作。
4. 分布式锁：保证同一时刻只有一个请求在处理，但要处理好锁的粒度与超时。

取舍

没有银弹。唯一约束最稳但局限性强，锁最灵活但引入复杂度。实际项目里往往是组合使用，按业务语义选择最合适的那一层。

Redis 的高可用，最常用的两条路是哨兵（Sentinel）和集群（Cluster）。选型之前，先想清楚自己的真实需求。

哨兵（Sentinel）

主从 + 哨兵监控，主挂自动切换。适合数据量不大、但对可用性有要求的场景。优点是简单、兼容性好，缺点是数据集中在一台主节点上，受内存上限制约。