Long-Horizon Agent 与 AI-SRE 行业趋势讨论总结
日期: 2026-02-27
来源: 微信公众号文章阅读与深度讨论
主题: 2026 Long-Horizon Agent 投资地图与 AI-SRE 行业应用
一、原文核心内容总结
1.1 文章背景
文章来自微信公众号「海外独角兽」，标题为《OpenClaw 是一个信号｜2026 Long-Horizon Agent 投资地图》，由 Haina 撰写。
文章核心观点：OpenClaw 的爆发标志着 AI Agent 从”辅助工具”向”数字劳动力”的范式转变，这将重塑企业软件市场的价值逻辑。
1.2 核心概念：Long-Horizon Agent
定义: 能够跨越数小时甚至数天执行复杂任务，并在异步系统之间持续运行的 AI Agent。
关键特征:
| 特征 | 描述 |
|---|---|
| 长周期执行 | 能够维持数小时/数天的任务状态 |
| 自我纠错 | 在执行过程中持续自我纠错，而非按脚本机械运行 |
| 跨系统操作 | 能够处理跨系统、跨角色的复杂流程 |
| 结果交付 | 直接交付业务结果，而非仅提供建议 |
1.3 三大核心转变
转变1：从 SaaS 到 Selling Labor
市场规模对比:
- SaaS 目标市场：全球约 3-4 千亿美元的企业软件支出
- AI Agent 目标市场：13 万亿美元的全球劳动支出市场
- 扩张倍数：30x TAM 扩张
定价逻辑转变:
| 模式 | 传统 SaaS | AI Agent |
|---|---|---|
| 收费依据 | 功能模块 | 交付结果 |
| 定价单位 | Seat（用户数） | Outcome（解决工单数/节省人力） |
| 价值锚点 | 提升效率 | 替代 FTE（全职等效人力） |
| 客户预算来源 | IT 工具采购 | 人力成本/业务损失 |
转变2：从 System of Record 到 System of Action
传统模式（System of Record）:
- 软件作为”记录系统”，依赖用户输入数据
- 例如：Salesforce 记录客户信息，但需要销售手动录入
- 企业不愿意做数据录入，导致数据质量差
新模式（System of Action）:
- 软件作为”行动系统”，直接执行任务
- 软件不再只是记录，而是直接执行
- 例如：Agent 自动分析邮件、挖掘客户、起草跟进
新的护城河：Workflow Data Gravity
“每一次任务运行，都会积累 Corner Cases、人类修正记录与 API 调用路径，这些数据并不会出现在公开训练集中，却能显著提升在特定企业环境中的准确率。”
数据资产类型:
| 数据类型 | 描述 | 价值 |
|---|---|---|
| 执行轨迹 | 任务执行的完整路径 | 训练专用 Agent |
| Corner Cases | 罕见边界情况 | 提升鲁棒性 |
| 人类修正 | 专家对 AI 决策的纠正 | 持续学习 |
| API 调用路径 | 系统间交互模式 | 优化执行效率 |
| 上下文映射 | 业务语境与技术指标的关联 | 提升准确性 |
转变3：从被动响应到主动介入（High Agency）
2026 年的交互范式转变:
| 维度 | 过去 | 未来 |
|---|---|---|
| 响应模式 | 被动响应用户请求 | 主动观察、建议、执行 |
| 角色定位 | 工具 | S 级员工（发现问题→研究→制定方案→执行→请求审批） |
| 交互界面 | 文本/图形界面 | Voice + 多模态 |
High Agency 五层金字塔:
Level 5: 自主执行 Autonomous Execution
↓ 获得授权后自动执行，事后汇报
Level 4: 主动建议 Proactive Suggestion
↓ 持续观察环境，主动提出方案
Level 3: 意图理解 Intent Comprehension
↓ 理解模糊目标，拆解为子任务
Level 2: 上下文感知 Context Awareness
↥ 持续感知系统状态和环境变化
Level 1: 任务执行 Task Execution
按指令完成具体操作
1.4 2026 Agent 投资四大方向
文章提出 2026 年 Agent 投资的四个核心方向：
方向1：Reasoning Orchestrators
核心功能: 让 Agent “工作得更久”的基础设施
解决的问题: Agent 在长周期任务中无法维持状态，遇到故障后无法恢复
关键技术: Durable Execution、State Management、Workflow Orchestration
代表公司: Temporal、Inngest、Parallel Web Systems
方向2：Process Intelligence
核心逻辑: 模型能力会趋同，执行经验不会
核心资产: Execution Traces（执行轨迹）- 记录过程数据，如”理赔专员在拒绝这个单子前，查阅了哪三份文档、在哪个格子里停顿了”
代表公司: Simular、Mimica
方向3：Selling Labor
核心转变: 真正的 Agent 公司卖结果，不是卖工具
判断标准: 客户是在为软件付费，还是在为”少雇一个人”付费
定价模式: 按 FTE 或 Outcome 定价
代表公司: Serval、Distyl AI、WithCoverage、Omnea
方向4：Voice Agents
核心定位: 劳动力的面孔
技术演进: 从 STT→LLM→TTS 拼装链路，走向端到端原生音频推理，延迟压到 300ms 以内，支持随时打断
关键场景: 医疗、保险、金融等高信任场景，语音是合规与情绪管理的重要载体
代表公司: 11labs、Cartesia、Sesame AI、HappyRobot、Further AI、Hippocratic AI
1.5 Long-Horizon Agent 的典型架构
文章提出了一个典型的 Long-Horizon Agent 技术栈：
┌─────────────────────────────────────────────────────────────┐
│ Interface 界面层 │
│ （11labs/Retell AI - Voice Agent / 企业IM / Web界面） │
│ 功能：接收用户输入，展示执行结果，支持多模态交互 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Brain 推理与编排层 │
│ （Distyl/Custom Model / 专用推理模型 + RAG） │
│ 功能：理解意图、拆解任务、推理决策、检索知识、生成计划 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Eyes & Hands 执行与操作层 │
│ （Simular / Computer-Use Agent） │
│ 功能：视觉感知、界面操作、API调用、跨系统执行、遗留系统操作 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Safety Net 持久化与容错层 │
│ （Temporal / Durable Execution） │
│ 功能：状态持久化、故障恢复、幂等性保证、超时处理、审计日志 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Evolution 学习与进化层 │
│ （Mimica / 过程挖掘） │
│ 功能：执行轨迹记录、模式识别、Skill提取、自动优化、知识沉淀 │
└─────────────────────────────────────────────────────────────┘
以保险理赔 Agent 为例的完整流程：
- Interface：客户车祸现场焦虑来电，Agent 毫秒级响应，语气冷静安抚并提取关键事实
- Brain：后台模型 RAG 检索保单条款，结合交通法规推理
- Eyes & Hands：模型判断需操作系统，但保险系统是20年前老古董无API，Agent 启动虚拟环境，操控鼠标登录后台完成审批生成PDF
- Safety Net：生成PDF时系统崩溃，Temporal 捕捉异常自动重试，流程不中断
- Evolution：整个流程记录为 Trace，处理得好则今晚自动加入微调数据集，明天 Agent 更聪明
二、关于 AI-SRE 的深度讨论
2.1 讨论背景
基于上述文章，我们针对 AI-SRE（人工智能驱动的站点可靠性工程） 这一具体领域展开了深入讨论。
2.2 核心议题：如何构建 Workflow Data Gravity
Workflow Data Gravity 是文章提出的核心概念，指的是 AI Agent 在实际工作过程中积累的执行轨迹、人类反馈、系统状态等数据资产。
2.2.1 Workflow Data Gravity 的本质
不是”收集数据”，而是”设计数据飞轮”
错误思维：
- 先做事 → 顺便记录 → 事后整理
正确思维：
- 设计执行系统 → 数据自然沉淀 → 形成自强化飞轮
2.2.2 四层数据沉淀架构
| 层级 | 名称 | 核心内容 | 技术实现 |
|---|---|---|---|
| L1 | 执行轨迹自动捕获 | 人类专家的数字孪生：屏幕操作、命令行、决策逻辑 | 录屏+视觉解析、Shell history、结构化记录 |
| L2 | 系统行为持续观测 | 全链路可观测性：Metrics、Logs、Traces、Events | Prometheus、ELK、Jaeger、Event Sourcing |
| L3 | 知识形式化沉淀 | 从隐性知识到显性知识：Runbook结构化→知识图谱 | 决策树、嵌入向量、RAG、大模型+知识图谱 |
| L4 | 飞轮闭环运转 | 数据→模型→产品→更多数据 | 自动化反馈、A/B测试、持续学习 |
2.2.3 关键成功因素：人工反馈的捕获
最重要的数据不是”做了什么”，而是”哪里错了”
反馈类型：
| 反馈类型 | 说明 | 价值 |
|---|---|---|
| 纠错反馈 | 专家推翻AI决策 | 最高价值，直接纠正错误 |
| 补充反馈 | 专家补充AI遗漏的上下文 | 完善决策依据 |
| 确认反馈 | 专家确认AI决策正确 | 用于强化学习正样本 |
| 改进建议 | 专家对流程的优化建议 | 用于Skill进化 |
实现机制：
- 每个AI建议后强制收集专家评分（1-5星）
- 专门的人工反馈界面，支持结构化标注
- 事后复盘会议中结构化记录专家决策
- 激励机制：反馈积分、排行榜、徽章系统
2.3 从执行轨迹提取 Skill 的算法框架
class SkillEvolutionEngine:
"""从执行轨迹中提取和进化 Skill 的引擎"""
def process_execution_trace(self, trace: SkillExecutionTrace):
"""处理单个执行轨迹"""
# 1. 模式识别
pattern = self.pattern_matcher.identify(trace)
# 2. 判断是否是新模式
if self.is_novel_pattern(pattern):
# 创建新的 Skill 草稿
new_skill_draft = self.skill_extractor.extract(trace, pattern)
self.propose_new_skill(new_skill_draft)
# 3. 更新现有 Skill
existing_skill = self.find_matching_skill(trace)
if existing_skill:
updated_skill = self.evolve_skill(existing_skill, trace, pattern)
if self.significant_improvement(existing_skill, updated_skill):
self.propose_skill_update(updated_skill)
# 4. 提取子 Skill
sub_skills = self.skill_extractor.identify_sub_skills(trace)
for sub_skill in sub_skills:
if self.is_reusable_sub_skill(sub_skill):
self.propose_new_sub_skill(sub_skill)
2.4 对 AI-SRE 的战略启示
2.4.1 定位建议
| 维度 | 建议 |
|---|---|
| 商业模式 | 从”卖工具”转向”卖劳动力”，按替代的 SRE 人力（FTE）或业务结果收费 |
| 定价锚点 | 价值锚点从”功能”转向”结果”，客户为”少雇一个人”或”避免一次故障损失”付费 |
| 技术路线 | Reasoning Orchestrator + System of Action + Safety Net 三层架构 |
| 竞争壁垒 | Workflow Data Gravity，积累垂直领域的执行轨迹和专家经验 |
2.4.2 技术栈架构建议
┌─────────────────────────────────────────────────────────────┐
│ Interface 界面层 │
│ （企业IM / Web界面 / 移动端 / 语音交互） │
│ 功能：告警接入、工单系统、自然语言交互、执行结果展示 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Brain 推理与编排层 │
│ （专用推理模型 + RAG知识检索 + 决策编排） │
│ 功能：告警理解、根因分析、影响评估、决策推理、计划生成 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Eyes & Hands 执行与操作层 │
│ （云平台API / K8s操作 / 数据库管理 / 中间件运维） │
│ 功能：自动化执行、配置变更、弹性伸缩、故障隔离、数据操作 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Safety Net 持久化与容错层 │
│ （Durable Execution / 状态管理） │
│ 功能：状态持久化、故障恢复、幂等性保证、超时处理、审计日志 │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Evolution 学习与进化层 │
│ （执行轨迹记录 / Skill提取 / 自动优化） │
│ 功能：数据沉淀、模式识别、Skill提取、持续学习、知识图谱构建 │
└─────────────────────────────────────────────────────────────┘
2.5 实施路径建议
| 阶段 | 时间 | 重点任务 | 里程碑 |
|---|---|---|---|
| Phase 1 | 1-2个月 | Skill基础设施搭建 | Skill定义规范、Registry、执行引擎 |
| Phase 2 | 2-4个月 | 核心场景Skill化 | 3-5个高频故障场景端到端Skill |
| Phase 3 | 4-8个月 | Skill生态建设 | 20+子Skill库、组合编排、内部市场 |
| Phase 4 | 8-12个月 | 智能化演进 | 自优化引擎、自动生成、跨团队共享 |
三、关键概念解释
3.1 FTE（Full-Time Equivalent）
定义: 全职等效，衡量人力工作量的标准单位。
示例:
- 1 FTE = 1个全职员工（每周40小时）
- 0.5 FTE = 半个全职员工（兼职20小时/周）
在 AI Agent 语境中的应用:
“这个 AI Agent 能完成原本需要 3个SRE工程师（3 FTE） 的工作，公司就可以减少雇佣这3个全职员工，从而节省人力成本。”
为什么用 FTE 而非直接说”人”:
| 场景 | 优势 |
|---|---|
| 人力资源规划 | 统一度量兼职、全职、外包的不同工作量 |
| 成本核算 | 总人力成本 = FTE × 人均成本 |
| 自动化替代评估 | 量化 AI Agent 替代了多少人力 |
| 跨国团队 | 不同国家工作时间差异大，FTE 提供统一标准 |
3.2 Workflow Data Gravity
定义: 指 AI Agent 在实际工作过程中积累的执行轨迹、人类反馈、系统状态等数据资产，这些数据形成”引力”，使得 Agent 在特定场景中越来越智能，且难以被通用模型替代。
核心洞察:
“每一次任务运行，都会积累 Corner Cases、人类修正记录与 API 调用路径，这些数据并不会出现在公开训练集中，却能显著提升在特定企业环境中的准确率。”
四层数据沉淀架构:
| 层级 | 名称 | 核心内容 |
|---|---|---|
| L1 | 执行轨迹自动捕获 | 屏幕操作、命令行、决策逻辑 |
| L2 | 系统行为持续观测 | Metrics、Logs、Traces、Events |
| L3 | 知识形式化沉淀 | Runbook结构化 → 知识图谱 |
| L4 | 飞轮闭环运转 | 数据→模型→产品→更多数据 |
3.3 Skill（技能）
定义: 在 AI Agent 语境下，Skill 是指可独立执行、可复用、可组合、可进化的模块化能力单元。它是从执行轨迹中提取的形式化知识资产。
Skill 的核心特征:
| 特征 | 描述 |
|---|---|
| 可独立执行 | 有明确的输入、输出、触发条件 |
| 可复用 | 可被不同场景、不同 Agent 调用 |
| 可组合 | 多个 Skill 可编排成更复杂的工作流 |
| 可进化 | 基于执行反馈持续优化改进 |
| 可解释 | 执行过程透明，可被人类理解和审计 |
Skill 的层次结构:
Domain-Specific Skills（垂直领域Skill）
↓ 组合、编排
Cross-Domain 通用 Skills（跨领域可复用Skill）
↓ 调用、封装
Foundation 基础设施 Skills（基础执行能力）
四、关键洞察与结论
4.1 对 AI-SRE 行业的核心启示
-
范式转变: AI-SRE 正从”辅助工具”向”数字劳动力”转变，核心价值从”提升效率”变为”替代人力”
-
商业模式创新: 应从”卖工具”转向”卖劳动力”，按替代的 SRE 人力（FTE）或业务结果收费
-
技术架构: 采用 Reasoning Orchestrator + System of Action + Safety Net 三层架构
-
竞争壁垒: Workflow Data Gravity 是核心壁垒，需要持续积累垂直领域的执行轨迹和专家经验
4.2 Skill 化的核心价值
从传统 ML 到 Skill 化的转变:
| 维度 | 传统 ML 模型 | Skill 化 |
|---|---|---|
| 可解释性 | 黑盒 | 白盒，步骤清晰 |
| 可审计性 | 难以追溯 | 完整记录决策路径 |
| 可控性 | 难以干预 | 可在任何步骤人工介入 |
| 可复用性 | 模型权重难以拆分 | Skill 可组合、可继承 |
| 进化速度 | 需大量数据重训练 | 可局部更新、快速迭代 |
| 人类协作 | 难以结合专家知识 | 设计为与人类协作 |
4.3 实施路径建议
| 阶段 | 时间 | 重点任务 | 里程碑 |
|---|---|---|---|
| Phase 1 | 1-2个月 | Skill基础设施 | Skill定义规范、Registry、执行引擎 |
| Phase 2 | 2-4个月 | 核心场景Skill化 | 3-5个高频故障场景端到端Skill |
| Phase 3 | 4-8个月 | Skill生态建设 | 20+子Skill库、组合编排、内部市场 |
| Phase 4 | 8-12个月 | 智能化演进 | 自优化引擎、自动生成、跨团队共享 |
五、关键术语速查表
| 术语 | 英文 | 定义 | 应用场景 |
|---|---|---|---|
| FTE | Full-Time Equivalent | 全职等效，衡量人力工作量的标准单位 | 量化AI Agent替代的人力成本 |
| Workflow Data Gravity | - | AI Agent积累的执行轨迹、反馈、状态等数据资产 | 形成竞争壁垒，提升垂直场景准确率 |
| Skill | - | 可独立执行、复用、组合、进化的模块化能力单元 | 从执行轨迹提取的形式化知识资产 |
| Long-Horizon Agent | - | 能跨越数小时/数天执行复杂任务的AI Agent | 替代人类完成长周期复杂工作 |
| Reasoning Orchestrator | - | 负责任务拆解、推理决策、编排执行的层 | 大脑层，理解意图、制定计划 |
| System of Action | - | 直接执行操作、交付结果的层 | 手脚层，调用API、操作系统 |
| Selling Labor | - | 按结果/人力替代收费的商业模式 | 从卖工具转向卖劳动力 |
| Outcome-based Pricing | - | 按业务结果（如解决工单数）定价 | 与价值直接挂钩的定价方式 |
| Durable Execution | - | 任务状态持久化，故障后可恢复 | 保证长周期任务可靠执行 |
文档结束