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) 颠覆了这一范式。 其核心流程是:
![图片[1]-LangAlpha是如何在架构上实现Harness 和 Loop Engineering - AI资源导航站-AI资源导航站](https://www.aitube.vip/wp-content/uploads/2026/07/20260709_6a4f4aaa1aab1.jpg)
这一设计的工程含义是深远的: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 中的完整呈现
![图片[2]-LangAlpha是如何在架构上实现Harness 和 Loop Engineering - AI资源导航站-AI资源导航站](https://www.aitube.vip/wp-content/uploads/2026/07/20260709_6a4f4aaa20d61.jpg)
六、结语:终极公式的工程实践
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也许能够提供一些思考的帮助。












