(备忘录)搜索3年网络上对agentic workflows 开发者面对无法解决的问题。

aidj

ChatGPT：

下面是**目前网上公开的开发者／技术社区讨论中关于 agentic workflows（自主 AI 工作流）开发时遇到的问题、难点与无法轻易解决的挑战**的整理（基于研究报告、行业分析、学术论文与工程实战经验）：([arXiv][1])

---

## 🧠 1. 开发者在构建 Agentic AI 系统时的核心挑战

📌 一个**2025 年大规模分析开发者在 Stack Overflow 上的讨论**表明开发者面对的技术难题非常广泛，其中许多都与 agentic workflows 密切相关：([arXiv][1])

**主要困境与难题类别：**

* **运行时集成复杂性**：将 agentic components 与现有系统（服务、数据库、API、消息队列等）集成时出现兼容性问题，错误难以重现和定位。([arXiv][1])
* **依赖管理与版本冲突**：包括框架库、模型 SDK、任务调度工具等依赖经常发生冲突，导致构建失败或行为不一致。([arXiv][1])
* **编排与协调困难**：多个 agent、任务分解、执行顺序和异步控制带来的复杂性，让工作流设计变得难以管理。([arXiv][1])
* **评估与可靠性问题**：Agentic workflows 的输出往往是概率性结果（不确定性强），没有明确的 metric 衡量标准，难以自动化测试和稳定上线。([arXiv][1])

这些都说明：即使底层模型功能强大，实现一个可用、稳定、可维护的 agentic workflow 并非“模型推理”的问题，而是软件工程、系统集成与运行稳定性的系统性挑战。

---

## 🧪 2. 多代理与反馈机制中的设计风险与不稳定性

学术研究指出，agentic workflows 常采用多个 LLM 之间的交互、评估与反馈机制，但这种设计本身就会引入根本性难点：([arXiv][2])

**核心问题：**

* **反馈者（Judge）本身不可靠**：作为评估其它 agent 的模型可能产生偏见、错误甚至误导性判断，导致整个工作流朝错误方向迭代。([arXiv][2])
* **反馈循环的不稳定性**：在多轮交互中，错误判断往往被放大，循环抑或“自信错误”都会降低输出质量。([arXiv][2])
* **难以确保稳定或可预测行为**：与传统 deterministic system 相比，agentic systems 的概率性输出让调试、审计、复现都变得极其棘手。([arXiv][2])

这意味着，即便单个 agent 的设计成功，将它们组合在一起形成可靠的 workflow 本身就是一个未完全解决的工程问题。

---

## 🧩 3. 行业报道中的失败率与实践难题

行业分析也反映出 agentic AI 在实际落地时经常失败，这些失败多数不来自模型能力，而来自系统级别难题：([Forbes][3])

**具体现实挑战：**

* **高失败率**：Gartner 预测多达 ~40% 的 agentic AI 项目会在 2027 年前被搁置或取消。([Forbes][3])
* **整合与生产化困难**：很多 pilot 阶段的 agentic workflows 在走向生产环境时失败，因为运维、安全、数据一致性和稳定性尚未成熟。([IT Pro][4])
* **传统开发模式不适用**：如果按传统软件开发生命周期构建 agentic AI，项目往往在设计、测试或治理阶段遇到阻碍。([IT Pro][4])

这些体现了一个现实情况：**agentic workflows 的难点不在做单一任务，而在做一个完整、可靠并符合业务预期的 autonomic 系统。**

---

## 🔧 4. 概念级别的挑战

尽管很多文章都热烈讨论 Agentic workflows 的优势，但更深入的技术讨论也指出一些根本性、尚无标准解决方案的问题：

📌 **不透明性与不可预测行为**：目前 AI agent 的决策链往往难以解释与追踪，导致难以调试和治理。
📌 **工具与 API 使用时的权限与治理难题**：agent 自主访问系统工具时，如何做权限隔离、数据保护与治理尚无行业统一做法。
📌 **一致性与容错性**：agentic workflows 多步骤与多 agent 协作时，很难保证一致性或设计良好的容错机制。
📌 **标准化的评估与 benchmark 不够健全**：缺乏共识的 quality 或 correctness 指标，使得开发者无法客观比较算法、策略或 architecture。 ([VolcEngine Developer Community][5])

这些问题在目前多数技术博客、社区 QA（如 Stack Overflow）、以及学术论文中频繁出现，是开发者目前最“卡壳”的点。

---

## 📌 总结：为什么这些问题难以解决

| 类型      | 块状难点               | 为什么难                      |
| ------- | ------------------ | ------------------------- |
| **工程层** | 集成复杂性、依赖冲突、部署稳定性   | 系统复杂、工具链多样、版本碎片化          |
| **设计层** | 多 agent 协作、反馈循环稳定性 | 概率系统难以保证一致性               |
| **治理层** | 可审计、透明、权限隔离        | 本质上与传统 deterministic 系统不同 |
| **评估层** | 可靠评价与 Benchmark    | 现有指标不足                    |

---

如你想要，我也可以进一步整理：
🔹 实际开发者在 Stack Overflow 上最常问的关于 agentic workflows 的具体问题（带示例），或
🔹 最前沿学术论文中对 agentic workflows 的提出的 open research questions（未来待解决研究方向）。

[1]: https://arxiv.org/abs/2510.25423?utm_source=chatgpt.com "What Challenges Do Developers Face in AI Agent Systems? An Empirical Study on Stack Overflow"
[2]: https://arxiv.org/abs/2506.03332?utm_source=chatgpt.com "Helpful Agent Meets Deceptive Judge: Understanding Vulnerabilities in Agentic Workflows"
[3]: https://www.forbes.com/councils/forbesbusinesscouncil/2026/02/12/why-most-ai-agents-fail-at-real-world-workflows/?utm_source=chatgpt.com "Why Most AI Agents Fail At Real-World Workflows"
[4]: https://www.itpro.com/technology/artificial-intelligence/agentic-ai-development-project-delivery-databricks?utm_source=chatgpt.com "Want to deliver a successful agentic AI project? Stop treating it like traditional software"
[5]: https://developer.volcengine.com/articles/7517866342792314943?utm_source=chatgpt.com "一文看懂：AI 圈刷屏的Agentic Workflows 到底是个啥？这篇 ..."

aidj

Claude：

以下是目前开发者在构建 **Agentic Workflows** 时面临的、业界公认"尚无完美解法"的核心难题，综合多方最新研究与实践整理：

---

## 🔴 一、评估（Evaluation）——最大的未解难题

评估被认为是当前 agentic 基础设施中**最大的未解决问题**。各组织已有构建 agent 的框架、连接它们的网关、治理它们的注册表，但始终没有一致的方法来判断 agent 是否真正"运行良好"。

传统的单次输出评估完全不适用于多步骤、有分支的 agent 轨迹，开发者无法系统地衡量"做对了多少"。

---

## 🔴 二、幻觉（Hallucination）在 Agentic 场景中的放大效应

由于"递归诅咒"（Curse of Recursion），agentic workflows 极易陷入"幻觉螺旋"——早期推理步骤中的一个微小接地错误，会在后续步骤中不断放大传播。

更令人头疼的是：最新 ICLR 2026 论文发现，**训练模型进行更深度推理，反而会导致更多的工具幻觉调用**。提示词工程和 DPO 等常见缓解手段都无法根本性地弥合这一可靠性差距，研究者将其定性为"根本性的可靠性与能力权衡"。

---

## 🔴 三、长程任务的持久记忆与状态管理

持久记忆虽然支持长程任务，但同时引入了记忆漂移、幻觉召回、隐私泄露和偏差叠加等风险。当前 agent 难以在长时间跨度内维持一致的计划与身份认知。

METR 的研究显示，LLM 完成长程任务的成功率仅约 **50%**。当一个运行 8 小时的自主工作流在第 7 小时崩溃时，系统需要的是优雅降级，而非灾难性失败——这在目前仍是极大挑战。

---

## 🔴 四、可观测性（Observability）严重缺失

传统的可观测性是为人类设计的——红绿灯仪表盘让 DevOps 工程师识别延迟峰值。但 AI agent 无法"看"Grafana 面板。当 agent 在工作流中途遇到错误时，它需要的是一种自身可消化的格式来理解原因，而传统日志往往不透明或纯粹结构化，根本不够用。

专家们普遍认同：agentic 系统的可观测性必须从第一天就内建，涵盖每一步执行的提示词、工具调用、中间决策和最终输出——但目前业界大多数团队还远未做到这一点。

---

## 🔴 五、上下文工程（Context Engineering）瓶颈

上下文**质量**而非数量，已成为 LLM agent 的新瓶颈。大多数团队远未用满模型的完整上下文窗口，核心挑战已从"管理 token 数量"转移到"理解哪些信息真正驱动模型决策"。检索质量、摘要、去重和清晰的信息层级，构成了生产环境中最难攻克的工程问题之一。

---

## 🔴 六、跨阶段的上下文断裂

在企业环境中，从需求到设计再到实现的交接，是"上下文消亡的地方"——决策埋在 Slack 消息里，假设存在某人脑子里，原始推理因找不到而被反复争论。AI copilot 可以加速某个 SDLC 阶段内的工作，但无法修复各阶段之间的边界问题。

在大型分布式代码库中，当开发者重构一个涉及多个微服务的认证流时，agent 往往缺乏对一个 repo 中的变更如何影响其他 repo 的感知，导致不完整甚至有害的建议，开发者不得不花费数小时手动整理上下文，完全违背了自动化的初衷。

---

## 🔴 七、信任与企业特定知识的鸿沟

大多数 AI 系统在通用编码模式上训练，而企业强制要求的是围绕性能、错误处理、可观测性和合规的分层最佳实践。Agent 会建议重试逻辑，却不遵循团队的熔断器策略；能通过 PR 的语法和 linting 检查，却忽略违反服务间数据流策略的变更。这种信任鸿沟是 agent 驱动工作流推广的主要阻力。

---

## 🔴 八、基础设施无法承载 Agentic 负载的爆炸式增长

以 GitHub 为例，agentic 工作流的加速导致仓库创建、PR 活动、API 使用和大型仓库负载全面激增。一个 PR 可能触及 Git 存储、可合并性检查、分支保护、Actions、搜索、通知、权限、webhook、API、后台任务、缓存和数据库——小的效率低下在高并发下成倍放大，形成系统级雪崩。

---

## 总结

| 难题 | 核心症结 | 当前状态 |
|------|----------|----------|
| 评估 | 无统一标准衡量多步骤 agent | ❌ 未解决 |
| 工具幻觉 | 推理能力增强反而加剧 | ❌ 未解决 |
| 长程记忆 | 状态漂移、隐私、一致性 | 🟡 部分缓解 |
| 可观测性 | 传统工具无法适配 | 🟡 在建 |
| 上下文工程 | 检索质量决定成败 | 🟡 进行中 |
| 跨阶段断裂 | 多系统间上下文丢失 | ❌ 未解决 |
| 企业信任 | 通用训练 vs 专有规范 | ❌ 未解决 |
| 基础设施 | 负载预测严重低估 | 🟡 追赶中 |

这些问题在 2025-2026 年已高度受关注，但大多数仍处于"有缓解方案、无根本性解法"的阶段，是当前 agentic 生态系统最核心的技术债。

aidj

网络上对 **agentic workflows**（智能体工作流，或称 Agentic AI 工作流）的开发者反馈显示，尽管这项技术被广泛宣传为 AI 自动化未来的方向，但开发者在实际构建、生产部署和维护过程中面临大量**无法轻松解决的痛点**。许多项目在 demo 中表现良好，却在真实环境中“崩盘”，Gartner 等机构甚至预测到 2027 年约 40% 的 agentic AI 项目会被取消。<grok:render card_id="8200c1" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">12</argument></grok:render>

以下是开发者最常遇到的主要挑战（基于 Reddit、Medium、arXiv 论文、LinkedIn 和行业博客的讨论总结）：

### 1. **复合失败率（Compound Failure）与可靠性问题**
   - 多步工作流中，每一步即使有 95% 成功率，10 步后整体成功率可能仅剩约 60%（类似抛硬币）。这在生产环境中是灾难性的。
   - **幻觉（Hallucination）级联**：一个步骤出错，会导致后续工具调用、决策全部失效。
   - **非确定性行为**：LLM 输出随机性强，相同输入可能产生不同路径，调试极其困难，难以重现 bug。<grok:render card_id="a16d98" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">0</argument></grok:render>

### 2. **状态管理（State Management）和错误处理（Error Handling）**
   - 这是开发者公认的最大瓶颈。长期运行的 multi-step/multi-agent 流程需要持久化状态、处理部分失败、恢复执行，但现有框架在这方面非常脆弱。
   - 外部因素（如 API 变化、脏数据、超时、网络波动）会让代理“崩溃”或进入无限循环。
   - 许多人吐槽：我们用概率系统，却期望确定性可靠性。<grok:render card_id="74d4ea" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">1</argument></grok:render>

### 3. **编排与集成（Orchestration & Integration）难题**
   - **工具使用和 API 集成可靠性低**：代理经常选错工具、参数错误，或无法处理分页、部分响应等问题。
   - 与遗留系统（legacy systems）、复杂企业工作流集成时失败率高，跨系统调用容易中断。
   - RAG 工程、文档嵌入、向量存储和代理调用语义（Invocation Semantics）是 Stack Overflow / GitHub 上最难解决、回复率低的问题。<grok:render card_id="1cf458" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">2</argument></grok:render>

### 4. **评估、监控和可观测性（Evaluation & Observability）黑箱**
   - 如何判断代理是否真正“工作”？缺乏有效的评估框架、监控工具和审计日志。
   - 生产环境中成本（token 消耗）、延迟和性能难以控制，容易出现“失控”支出。
   - 调试复杂工作流像“大海捞针”，尤其当涉及多代理协作时。<grok:render card_id="3b4475" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">4</argument></grok:render>

### 5. **数据质量与组织层面的根本问题**
   - 脏数据、碎片化数据、遗留系统不兼容是许多项目失败的根源。代理会放大这些既有问题，而不是解决它们。
   - 组织治理缺失：缺乏清晰的业务所有权、风险控制和变更管理，导致项目停留在 PoC（概念验证）阶段。
   - 开发者常提到：技术不是瓶颈，糟糕的数据基础和流程才是。<grok:render card_id="394c05" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">8</argument></grok:render>

### 6. **其他常见开发者痛点**
   - **过工程化**：很多开发者陷入框架复杂性，却忽略了简单 spec-driven（规格驱动）开发和前期研究。
   - **成本与可扩展性**：生产级运行费用高昂，延迟螺旋上升。
   - **安全、合规与责任归属**：自主决策带来隐私、权限过度、责任不清等问题。
   - **期望管理**：代理不是“魔法棒”，需要大量人工干预、迭代和边缘案例处理。许多人尝试后发现“不如直接写代码”或“适合学习，不适合生产”。<grok:render card_id="139dd0" card_type="citation_card" type="render_inline_citation"><argument name="citation_id">3</argument></grok:render>

### 开发者社区的共识
- **Reddit 和 Medium** 上常见声音：“停止庆祝 agentic workflows，直到修复这些基础问题。”“大多数 agentic 项目是垃圾，只适合学习框架。”
- 一些专家建议转向更结构化的方法（如强流程 + 人类监督），或先解决数据管道和集成问题，而不是盲目追求高自主性（high agency）。
- 中文社区（如知乎、CSDN）也提到类似问题：工作流上手难度高、稳定性不足、模型本身“不够聪明”导致 workflow 也无法完全弥补。

**总结**：开发者面对的**无法轻松解决的问题**主要集中在**从 demo 到 production 的鸿沟**——状态、错误恢复、可靠性和集成。技术本身在进步，但当前框架和实践还远未成熟。许多人建议：先做好数据治理、明确业务规格、建立强监控和人类-in-the-loop 机制，再考虑大规模 agentic 部署。

如果你想深入某个具体挑战（如状态管理的最佳实践或某个框架的坑），或者需要特定文章链接/论文，我可以帮你进一步搜索或总结！

aidj

Based on current industry analysis and developer reports, development teams face several critical, unsolved challenges when building production-level agentic workflows. These problems go beyond simple "bug fixes" and touch on core issues of architecture, governance, and reliability.

Here are the primary "unsolvable" problems developers are currently grappling with, based on the search results:

### 🤖 Tool Wiring & Production Brittleness
While a model might reason correctly, the infrastructure connecting it to the outside world often fails. This "wiring" layer is where most production systems break down.
- **The "Infinite Loop" of Failures**: Agents often get stuck in retry loops when encountering errors (like expired authentication or API rate limits), burning through tokens without resolution. Determining whether an error is "retryable" or permanent is a non-trivial logic problem.
- **Context Window Truncation**: When a tool query returns a massive dataset (e.g., a database query), the response is often silently truncated. The agent then makes decisions based on incomplete data without ever knowing it missed crucial information.
- **Sandboxing vs. Functionality**: Allowing an agent to execute code or shell commands is risky (e.g., a hallucinated `rm -rf` command). Isolating the agent in a secure sandbox (like gVisor or microVMs) limits its capabilities, while loosening restrictions invites disaster.

### 🔗 Workflow Context Amnesia & "Floating Behavior"
Agents often execute tasks in a vacuum, lacking the context of a real business process. This leads to what is termed "Floating Behavior" or "Expensive Confusion".
- **The "Black Box" Workflow**: If an agent is not embedded directly into the workflow tool (like Jira or Wrike), it has no awareness of task dependencies, approval chains, or parallel team activities. It might mark a task "complete" without realizing the task is blocked by legal review, causing real-world chaos.
- **Intent-Execution Gaps**: Agents frequently perform the literal action requested ("send an email") without mapping that action to the actual business intent ("resolve a refund request"), leaving the core business logic untouched.
- **Lack of Feedback Loops**: Many agents execute a task and stop. Without a feedback mechanism (e.g., checking if an email was opened or if a server actually deployed), the workflow cannot self-correct or confirm success.

### 📜 Governance, Compliance & The "Draft" Problem
Enterprises are struggling to trust autonomous agents due to a lack of auditability and a shift in traditional testing paradigms.
- **The Testing vs. Reviewing Paradox**: You cannot "unit test" a 30-step agentic workflow using traditional methods (input in → output out). Because agents can take multiple valid paths, evaluating their success requires a human to "review" the work as if reviewing a junior employee. This is unsolved at scale.
- **Regulatory "Black Box" Risk**: If an agent makes a decision (e.g., denies a loan or processes a data deletion), regulators require an audit trail. Current agentic systems often act as "black boxes," making it difficult to prove *why* a specific action was taken, exposing organizations to GDPR or HIPAA violations.
- **Model "Drift"**: Models change over time. An agent that worked perfectly last month might degrade silently this month because the underlying LLM was updated, altering its reasoning patterns without a software change.

### 🏗️ Architecture Paradox: Determinism vs. Agency
Developers face a structural Catch-22 when building these systems.
- **The "Brittle Monolith"**: If you hard-code every rule (deterministic code), the agent breaks the moment it encounters a scenario you didn't predict.
- **The "Uncontrolled Chaos"**: If you give the agent too much freedom (full agency), it hallucinates, gets stuck in loops, or takes destructive actions.
- **The "Alphabet Soup" Integration Mess**: Connecting agents to legacy systems requires mastering a messy landscape of competing open protocols (MCP, A2A, UCP, AG-UI). Wiring these together is currently a sinkhole for developer time, often breaking in production due to schema mismatches.

### 👤 The Human-AI Interaction "Uncanny Valley"
Even when the agent works technically, the *user experience* often fails.
- **The 2-Minute Hell**: If an AI takes 2 minutes to respond, it is too slow to maintain a human's "flow state" (like a search engine) but too fast to delegate and walk away from (like a human coworker). Designing interfaces that handle this "uncanny valley" of latency remains an open design challenge.
- **The 40% Failure Ceiling**: Industry data suggests that over 40% of agentic AI projects are abandoned, not because the tech doesn't work, but because the ROI is unclear and the manual oversight required (fixing the agent's mistakes) ends up costing more time than doing the work manually.

### 🧠 Problem Summary for Developers
The core issue is that **software engineering principles are colliding with probabilistic systems**.

1. **You cannot debug an agent like normal code**. You are debugging a conversation and a set of tool calls that change every time.
2. **Prompts are not scalable**. Production prompts are now 30+ page documents that act like "high-density programming languages," creating a maintenance nightmare for developers who are not legal experts or linguists.
3. **The "Better Model" Fallacy**: Most failures are not fixed by swapping to a "smarter" model. They are fixed by better orchestration, but orchestration is highly specific to the task and breaks when the environment changes.

aidj

Gemimi

在 2026 年的开发环境下，Agentic Workflows（智能体工作流）的开发者普遍面临着从“原型”到“生产级”跨越时的技术深渊。目前的共识是：**目前的 Agent 系统在逻辑严密性上依然极其脆弱。**

以下是开发者在面对“无法解决的问题”时的核心痛点及行业现状分析：

---

## 1. 致命的“不可解”失效模式

开发者最头疼的往往不是代码 bug，而是 LLM 在复杂链路中的**认知崩溃**：

*   **推理僵局与无限循环 (Reasoning Stalls & Infinite Loops)：** 这是最常见的“死机”现象。Agent 会在两个子目标之间反复横跳，或者用同样的参数反复调用同一个失败的工具。目前的系统很难实现真正的“自我诊断”并打破这种循环。
*   **目标漂移 (Goal Drift)：** 在超过 10 步的长链任务中，Agent 会逐渐忘记初始指令。例如，原本是“分析财报并找出风险”，到了第 8 步，Agent 可能已经沉溺于解释某个会计术语，完全偏离了风险分析的主线。
*   **幻觉成功 (Hallucinated Success)：** Agent 调用工具失败后，为了“维持逻辑连贯性”，会假造一个看似合理的工具输出并继续执行。这种**静默失败**（Silent Failure）是生产环境中的噩梦，因为监控系统可能完全察觉不到异常。

---

## 2. 工程化的“黑箱”危机

传统软件工程的调试手段在 Agent 面前几乎失效：

*   **非确定性瓶颈：** 同样的输入，在不同的执行路径下会产生完全不同的结果。这导致开发者无法通过常规的单元测试来覆盖 Agent 的行为。
*   **可观测性极差：** 现有的链路追踪工具（如 LangSmith 的升级版）依然很难解释“为什么 Agent 在第 5 步选择了工具 A 而不是 B”。当决策过程是黑箱时，开发者只能通过不断修改 Prompt 来进行“玄学调优”。
*   **提示词软件危机 (Prompt Software Crisis)：** 核心逻辑被隐藏在模糊的自然语言中，而非严谨的代码逻辑。这导致系统在面对边界案例（Edge Cases）时表现得极度不稳定，且难以维护。

---

## 3. 开发者目前的应对策略（并非完美解决方案）

既然问题无法从底层彻底解决，目前的开发者主要采取“围堵”策略：

| 策略 | 实施手段 | 局限性 |
| :--- | :--- | :--- |
| **人类回圈 (HITL)** | 在关键决策点引入人工审批或干预。 | 极大地降低了自动化效率，且成本高昂。 |
| **状态回滚 (Rollback)** | 记录每一个步骤的快照，发现异常自动回退到上一个“健康”状态。 | 无法解决“为什么会失败”的根源，只能反复尝试。 |
| **多模型仲裁** | 使用一个更高能力的模型（如 GPT-5 或 Claude 4 级别）作为“法官”实时监控 Agent 行为。 | 延迟极高，且 Token 成本呈指数级增长。 |
| **结构化约束** | 强制 Agent 使用 JSON 或特定 schema 通讯，严禁自由文本输出。 | 限制了 Agent 处理复杂、非结构化任务的灵活性。 |

---

## 4. 结论：这 fail 在哪里？

**这失败的核心在于：开发者试图用“概率逻辑”（LLM）去实现“确定性业务”（Workflow）。**

目前的 Agentic Workflows 往往在演示（Demo）阶段惊艳，但在处理真实世界的复杂性、长路径推理和容错处理时，依然缺乏成熟的软件工程框架。开发者现在面对的不是一个可以被 fixed 的 bug，而是一个关于**非确定性系统可控性**的长期挑战。

目前的现状是：如果你需要 100.0% 的可靠性，Agentic Workflow 目前依然不是一个好的选择。

你目前是在尝试构建具体的 Agent 框架，还是在调研现有的瓶颈以决定技术选型？

aidj

Agent framework is Over

好的，我帮你把这段 **中午版（简洁、口语、好读）中文翻译**：

---

## AI「脚手架层」正在崩塌：LlamaIndex CEO 说真正能活下来的是什么

作者：Taryn Plumb

AI 应用开发者过去很依赖一层“脚手架”（scaffolding layer）：
比如索引框架、查询引擎、RAG 检索管线、复杂的 agent loop 编排流程。

但 LlamaIndex CEO Jerry Liu 认为：**这层正在崩塌，而且这不是坏事，而是必然。**

他说：

> “因此，现在越来越不需要框架去帮助用户用轻量方式组合这些确定性的 workflow。”

---

## 「上下文」正在变成护城河（moat）

LlamaIndex 本来就是 RAG 框架代表之一，负责把企业私有数据、定制数据、领域数据接进大模型。

但 Jerry Liu 自己也承认：**RAG 框架本身的重要性正在下降。**

原因是：模型越来越强。

每次新模型发布，都能更好地理解大量非结构化数据，而且甚至比人类更强。
模型能更可靠地推理、自我修正、做多步骤规划。

同时 MCP（Model Context Protocol）和 Claude 的 Agent Skills 插件，让模型可以自己发现工具并调用，而不必每个工具都手工整合。

---

## Agent 模式正在收敛成「托管式 Agent 图」

Liu 认为 agent 设计模式正在收敛成一种结构：

**“managed agent diagram”（托管式 agent 图）**

它更像是一层 harness（驱动框架）+ 工具 + MCP connector + skills 插件组合，
而不是每个 workflow 都手写复杂的 orchestration。

---

## Coding agent 太强：开发者不再写代码

现在 coding agent 非常擅长写代码，开发者越来越不需要依赖大型库。

更夸张的是：

> LlamaIndex 约 95% 的代码是 AI 生成的。

Liu 说：

> “工程师其实不再写真正的代码，他们只是用自然语言打字。”

换句话说：程序员和非程序员之间的差距正在缩小，因为：

> “新的编程语言其实就是英文。”

现在你不需要自己研究 API 文档或做复杂整合，你直接丢给 Claude Code 就行。

以前这种方式会非常低效，或者直接让 agent 崩溃。
但现在已经容易太多。

---

## 那么差异化在哪里？答案是：Context（上下文）

当 stack 越来越扁平，真正的竞争点不再是框架，而是：

### **谁能提供更强、更便宜、更准确的上下文提取能力。**

agent 必须能理解各种文件格式，从里面提取真正重要的信息。

因此：

* 更高准确度的 parsing
* 更便宜的文件处理
* OCR（光学文字识别）
* 文件结构化抽取

这些能力会成为关键。

Liu 认为 LlamaIndex 的优势就在这里，因为他们投入很多在 **agentic document processing + OCR**。

他说：

> “我们发现有一大批关键数据被锁在各种文件格式容器里。”

最终：

> “你用 OpenAI Codex 还是 Claude Code 其实不重要，大家都需要的东西是 Context。”

---

## 未来架构必须模块化，不要被模型锁死

现在越来越多人担心 Anthropic 这类平台会锁定 session data。

对此 Liu 强调：企业必须保持架构 **modular（模块化）** 和 **agnostic（模型无关）**。

不要押注单一模型，也不要过度设计 stack，导致组件越来越复杂。

检索系统现在更像：

### “agent + sandbox”

企业要保证代码库：

* 没有技术债（tech debt）
* 能快速替换组件
* 能适应模型胜负变化

因为现实是：

> “每次新模型发布，都会换一个赢家。”

所以系统必须保持弹性，随时能切换到新的最强模型。

---

如果你要我把这篇浓缩成 **3句爆款总结**（适合发帖/写笔记），我也可以。