2026 年 6 月，Peter Steinberger（OpenClaw 作者）、Boris Cherny（Claude Code 负责人） 和 Addy Osmani（Google Chrome 团队）三位顶级工程师在一周内同时点燃了一个概念—— Loop Engineering。三人的共识指向同一个转变： 设计的对象从"Agent 的单次行为"转变为"驱动 Agent 的完整系统"。
这并非取代已有的 Prompt Engineering、Context Engineering 和 Harness Engineering， 而是在它们之上叠加第四层。每一层向上，关注的单元放大一号：
| 1 | Prompt Engineering | ||
| 2 | Context Engineering | ||
| 3 | Harness Engineering | ||
| 4 | Loop Engineering |
二、Harness Engineering：一次运行的设计
Harness Engineering 关注的是"一次 Agent 执行"这个单元——模型如何调用工具、 工具如何返回结果、中间件如何编排、基础设施如何隔离。 它不是写一个提示，而是设计承载提示、工具和模型的执行框架本身。 LangAlpha 在这层的设计由四个核心支柱构成。
2.1 PTC 模式：代码作为工具调用的中间层
传统的 AI Agent 通过 JSON 格式的工具调用与数据交互： 模型输出一个 JSON blob，后端解析后执行函数，再将原始数据塞回 context window。 这种做法有两个根本问题：一是大量原始数据涌入上下文，迅速消耗 token 预算； 二是 LLM 无法对数据做真正的计算——它只能"读"数据，不能"操作"数据。
LangAlpha 的 PTC（Programmatic Tool Call） 颠覆了这一范式。 其核心流程是：
这一设计的工程含义是深远的：LLM 充当"架构师"而非"搬运工"。 它写代码决定要拿什么数据、如何处理，但处理过程在沙箱中完成。 这是 Generator / Evaluator 分离的第一层体现—— LLM 生成方案，沙箱运行时验证结果。代码执行成功与否 （stdout / stderr / 文件产物）是客观事实，不依赖 LLM 的自我评价。
2.2 25 层中间件栈：约束的组合
LangAlpha 的 Agent 并非一个手写的 LangGraph StateGraph。 它通过 deepagents 库的 create_agent() 创建， 包裹在一个约 25 层的中间件链中。这个栈在 src/ptc_agent/agent/agent.py 中组装：
| 技能加载 | ||
| 子代理分发 | ||
| HITL | ||
| 上下文压缩 | ||
| 工作区注入 | ||
| 记忆感知 |
值得注意的是中间件的分层与解耦：安全约束（路径保护、泄漏检测） 在工具调用层；能力注入（技能、子代理）在编排层； 持久化感知（工作区注入、记忆）在上下文层。 每层独立演进，互不阻塞。这体现了 Stripe 架构的核心主张—— 可靠性来自约束的质量，而非模型的大小。
2.3 Daytona 沙箱：结构化的执行环境
沙箱生命周期
工作区目录结构
/home/workspace/
├── agent.md # 持久化工作区指令
├── work/
├── results/ # 最终报告
├── data/ # 共享数据集
├── tools/ # MCP Python 包装器
└── .agents/
├── user/ # 用户配置 + 记忆
└── skills/ # 技能模块每个工作区对应一个独立的 Daytona 沙箱 VM。 work/ 的任务隔离目录确保了并发子代理之间互不干扰—— 这正是 Loop Engineering 中 Worktrees 组件的实际落地。 沙箱快照基于 agent_config.yaml 的哈希值版本化， 确保工作区重建时依赖一致。
2.4 多模型弹性层
LangAlpha 通过一个提供商无关的模型层抽象了多个 LLM 后端： OpenAI (o3/o4-mini, GPT-4o)、Anthropic (Claude Sonnet/Opus 4)、 Google (Gemini 2.5)、DeepSeek (V3/R1)、Qwen、Kimi、Doubao、GLM、MiniMax 等。 两层弹性机制：
- 自动重试
：瞬时错误自动重试 - 故障转移
：通过 llm.fallback配置链式降级到备用模型 - 推理级别标准化
：不同提供商的 reasoning_effort 自动映射 - 双模式
：PTC 模式做深度多步分析，Flash 模式做快速对话
三、Loop Engineering：自运转循环的设计
Loop Engineering 的定义是：替换你自己作为给 Agent 下指令的人， 转而去设计一个能自动完成这件事的系统。它的三个核心能力是 定时运行、派生助手、自我喂养。 Anthropic 论文定义了 Loop 的五个动作和六个组件。 下面逐一映射 LangAlpha 的实现。
3.1 五动作的完整映射
pages/Dashboard/skills/ | 防 Blind Loop | ||
src/ptc_agent/agent/subagents/agent_config.yaml | 防 Tangled Loop | ||
agent_config.yaml → filesystem | 防 Nodding Loop | ||
MemoryContextMiddlewareCheckPoolsse_events | 防 Amnesiac Loop | ||
pages/Automations/agent_config.yaml → compaction | 防 Manual Loop |
3.2 六组件的工程落地
⚡ Automations
pages/Automations/ 定时研究 CRUD，模板库（Mag 7 财报前等），skills/automation/
🌲 Worktrees
Daytona 沙箱每工作区独立 VM，work/ 任务隔离，子代理隔离上下文
🧩 Skills
20+ 预构建技能（dcf-model、comps-analysis、earnings-preview 等），SkillsMiddleware 运行时加载
🔌 Connectors
10+ MCP 服务器（stdio/HTTP），FMP · SEC EDGAR · Polygon · Yahoo · X API · Scrapling
🤖 Sub-agents
5 内置 + 用户自定义，Task() 并行异步，update/resume 迭代，服务器重启后自动重建
🧠 Memory
用户级 + 工作区级持久记忆，Memo 存储（Markdown/PDF/CSV），LangGraph BaseStore + PG
3.3 Generator / Evaluator 分离：五层嵌套实现 ⭐
这是 Loop Engineering 方法论中最核心的设计原则。Anthropic 工程师 Prithvi Rajasekaran 的实证观察指出： "让 Agent 评判自己刚写的代码，它会自信地给出好评——即使质量平庸。" 这不是智商问题，而是结构性缺陷：Agent 的上下文里塞满了"为什么这样写"的自我说服链条， 它看到的不是结果，而是导致结果的理由。
LangAlpha 在五个不同层级上实现了 Generator/Evaluator 分离：
| L1 | ||||
| L2 | ||||
| L3 | ||||
| L4 | ||||
| L5 |
"可靠性来自约束的质量，而非模型的大小。"
L1 到 L4 构成了从"软约束"到"硬约束"的递进：L1 依赖运行时事实，L2 依赖隔离上下文， L3 依赖模式切换，L4 依赖不可绕过的确定性门控。L5 保留了人类的最终裁决权。 这个五层设计体现了一个关键认知：验证层的独立性必须与生成层同等级别地工程化， 而不是作为附属功能后加。
3.4 四种隐藏成本的防御体系
Loop Engineering 论文特别警示了四种静默积累的成本。 LangAlpha 在架构中为每一种都设置了防御：
📋 Verification Debt
应对：PTC 客观验证
代码执行结果非 LLM 自评；Flash 快速二次验证
📖 Comprehension Rot
应对：agent.md + 子代理视图
工作区级文档持久记录；子代理进度实时透明
🧠 Cognitive Surrender
应对：HITL + Steering
人类检查点内置在中间件中；用户可中途介入
💰 Token Blowout
应对：Compaction + PTC
120K token 阈值自动压缩；数据不入 context window
四、关键架构决策
4.1 BackgroundSubagentOrchestrator：派生助手的引擎
LangAlpha 的子代理系统通过 Task() 工具实现，这是 Loop Engineering 中"派生助手"能力的核心。关键设计决策：
并行执行，隔离上下文
子代理在独立的上下文窗口中运行，防止主代理的推理链漂移。 每个子代理返回浓缩结果给主代理，使编排器保持精简。 这解决了"一个 Agent 管太多事导致上下文膨胀"的核心问题。
update / resume：迭代而非重做
主代理可以向仍在运行的子代理发送后续指令（update）， 也可以用完整上下文恢复已完成的子代理继续优化（resume）。 服务器重启时，子代理状态从 LangGraph 检查点自动重建。
4.2 Memory 与 Memo：双重持久化体系
LangAlpha 实现了两个独立的持久化存储，均基于 LangGraph 的 BaseStore API：
| Memory | MemoryContextMiddleware | |||
| Memo | MemoAwarenessMiddleware |
Memory 对应 Loop 中"自我喂养"的能力——Agent 在运行中积累的知识（用户偏好、分析框架） 自动沉淀到持久存储中，下次会话自动注入。Memo 则让用户可以将外部知识注入系统。 两者共享请求作用域缓存，单轮中多次读取只命中存储一次。
"在 Loop 第一次无人值守运行前，设置单次预算、每日预算、最大重试次数。 这不是为了省钱，而是把开放式风险转化为有界风险。"
4.3 Compaction：Token 爆炸的自动防御
LangAlpha 的 Compaction 中间件是 Loop Engineering 中"Token Blowout"成本管理的直接实现。 其配置精确地体现了"有界风险"原则：
compaction:
enabled: true
token_threshold: 120000 # 超过此阈值触发压缩
keep_messages: 10 # 保留最后 10 条消息
truncate_args_trigger_messages: 40 # 超过 40 条消息时截断工具参数
truncate_args_keep_messages: 10 # 最近 10 条不做截断
truncate_args_max_length: 2000 # 每个参数值最多 2000 字符这个设计在"保留足够上下文让 Agent 继续工作"和"防止 token 无限堆积"之间找到了工程平衡点。 配合 PTC 模式（数据不进入 context window），LangAlpha 在多轮深度分析中能维持稳定的 token 消耗。
五、全景架构：四层栈在 LangAlpha 中的完整呈现
六、结语：终极公式的工程实践
LangAlpha 的架构设计体现了这个公式的三个关键维度：
第一，系统的完整性。 五个 Loop 动作（Discovery → Handoff → Verification → Persistence → Scheduling） 在 LangAlpha 中都有明确的代码级对应，不是概念上的"可以参考"而是工程上的"已经落地"。 六个组件也没有遗漏——从 MCP 服务器集群（Connectors）到 Memory/Memo 双存储（Memory）， 从 Skills 目录（Skills）到 Daytona 沙箱（Worktrees），再到 Automations 页面（Automations） 和子代理注册表（Sub-agents）。
第二，约束的层次化。 Generator/Evaluator 分离不是单一机制，而是五层嵌套——从最软的"依赖运行时事实"（L1 PTC） 到最硬的"确定性门控"（L4 路径白名单）再到"人类保留最终否决权"（L5 HITL）。 这个层次化设计意味着：即使某一层的验证被绕过，下一层仍然在起作用。
第三，成本的自觉防御。 LangAlpha 对 Loop 的四种隐藏成本（Verification Debt、Comprehension Rot、 Cognitive Surrender、Token Blowout）都设置了对应的架构防御——不是事后补救， 而是作为中间件栈和基础配置的内置约束。Compaction 中间件的三层截断策略 （全文压缩 / 参数截断 / 预算约束）尤其体现了"把开放式风险转化为有界风险"的工程思维。
对于正在构建金融Agent 系统的工程师而言，LangAlpha也许能够提供一些思考的帮助。
