设计哲学¶
Rein 不是一份纯技术规格,而是一连串「把大而全砍成极薄」的决策。这页讲为什么这么薄。
一句话定位¶
一个极薄但生产级的单-agent harness。对外只说那句「5 行把大模型变成能干活的 agent」。
「Harness 架构」(包裹并驱动大模型的运行时层)退居内部设计哲学,不作对外主推广语 —— 因为 90% 开发者不认识这个术语。
三条贯穿始终的主线¶
1. 机制进核心,实例走扩展,重依赖走 extras¶
- 核心依赖
pydantic+anyio+litellm(pip install rein-agent装完即接入真实大模型);docker / opentelemetry / typer 仍是可选 extras。 - 提供的是机制(loop 引擎、中间件调度、Provider/Runtime 协议),而不是预先塞满一堆内置功能。你用这些小而正交的机制拼出任意行为。
2. 可序列化的状态 + 无状态的推进¶
Session(可序列化状态)+ loop(无状态纯函数推进)这一条地基,让暂停、恢复、压缩、中间件全都成立。这是整个框架最关键的一个决策。
3. 反 LangChain 重抽象¶
不做多 agent 编排、不做 RAG 大生态。聚焦把「单 agent 的 loop + 工具 + 可控 + 可观测」这一件事做到极致。
关键决策(摘自设计总账)¶
| 决策 | 选择 | 为什么 |
|---|---|---|
| 语言 | Python | 给 Python 开发者用;AI 生态成熟 |
| 形态 | 脚手架 CLI + 运行时库 | 既能 import 用,也能一键起项目 |
| Loop | 可序列化单步状态机 | 部署「本地+服务端都要」→ 必须能跨进程暂停/恢复 |
| 多厂商 | wrap LiteLLM | 已覆盖 100+ 厂商,自研是重复造轮子 |
| 三对象 | Agent / Session / Chat 分离 | 否则并发会串台 |
| Runtime | Local + Docker,砍掉 Remote | 远程执行工具很重、需求极少(YAGNI) |
| 熔断 | 四道闸进核心 | 生产头号事故是死循环烧钱 |
| 扩展 | 收敛为一套中间件 | 不搞三套并列的重叠 API |
| 可观测 | 结构化 RunResult,OTel 走 extras | 数据是核心,导出是 adapter |
| 持久化 | Session 自序列化,不内置 store | 后端是用户的事 |
自我否决:怎么砍成「极薄」¶
设计过程是一刀刀做减法的:
- 从「大而全的 Agent 框架」→「极薄单-agent harness」。
- 砍掉 RemoteRuntime(投机性 YAGNI)。
- 不自研多厂商适配 → wrap LiteLLM。
- 中间件 / 钩子 / 事件不做成三套并列 API → 收敛成一套洋葱机制。
- 配置以代码为主,
rein.toml仅作可选备选。
「极薄」不是功能少,而是机制少而正交、依赖少而可选,但拼得出生产级的复杂行为。
最大的赌注¶
与 Pydantic AI 等高度重叠,差异在:极薄 + 可序列化状态机 + HITL/断点续跑 + 中文友好。这套地基是否值得,就赌在「可恢复」这件被多数框架忽视、却对真实生产部署至关重要的能力上。
想看完整推演,见仓库里的 docs/DESIGN.md(需求逐条 / 决策 / 否决的替代方案)。