当前位置：首页 > news >正文

智能体架构：统一运行框架、循环与图工程

news 2026/7/31 16:24:07

📝 TLDR：智能体不可靠几乎从来不是提示词问题，而是层级定位问题：环境与状态归运行框架层，停止条件归循环层，并发与路由归图层，这三者不是三种流派，而是同一个系统的三层结构。关键动作是让循环围绕确定性证据（测试退出码、linter 零告警）收敛，而不是围绕模型自称的「我做完了」；出故障时先判断症状属于哪一层，再去修那一层，而不是反复重写提示词。

大多数开发者把 Claude Code 和 LLM 智能体当作昂贵的实习生来用：他们给出一个提示，等待一次响应，再手动检查接下来会发生什么

其他团队则会陷入三种常见的失败模式：

他们运行无休止的重试循环，烧掉数千美元，却不检查代码能否通过编译
他们还没弄清楚单个子智能体如何工作，就开始绘制包含 50 个节点的庞大工作流图
他们反复改写提示，却忽略了底层环境

这三种方法之所以失败，是因为构建者将运行框架工程、循环工程和图工程视为彼此竞争的理念，但它们并不相互竞争，而是共同构成了同一个生产系统的三个结构层

┌─────────────────────────────────────────────────────────────┐│ HARNESS LAYER ││ (Environment, Sandboxes, State Persistence, Tool Caching) ││ ││ ┌────────────────────────────────────────────────────────┐ ││ │ GRAPH LAYER │ ││ │ (Topology, Parallel Fan-Out, Routing, Joins) │ ││ │ │ ││ │ ┌───────────────────────────────────────────────────┐ │ ││ │ │ LOOP LAYER │ │ ││ │ │ (Evidence Checks, Linters, Retry Rules) │ │ ││ │ │ │ │ ││ │ │ ┌──────────────────────────────────────────────┐ │ │ ││ │ │ │ MODEL │ │ │ ││ │ │ └──────────────────────────────────────────────┘ │ │ ││ │ └───────────────────────────────────────────────────┘ │ ││ └────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘

当构建者割裂这些层时，智能体只能停留在脆弱的演示阶段；当工程师将三者整合进同一个工作流后，一个提示就能产出经过验证、零缺陷的生产级 PR

| Architecture Layer |Primary Responsibility | Key Components | Failure Mode When Missing|| --- | --- | --- | --- ||Harness Layer | Environment & Persistence |Sandboxes, .claude/ configs, tool caching, state hashing | State lost between turns, file read token leaks||Loop Layer|Feedback & Quality Gates|Deterministic test runners, linter checks, budget caps|Hallucinated completions, broken code claims||Graph Layer|Flow Control & Concurrency|Scoping nodes, parallel fan-out, routing, sync joins|Sequential execution bottlenecks, wrong routing|

深入解析：运行框架层（环境与状态）
====================

运行框架由模型之外的代码、配置、沙箱、git 历史记录和记忆组成

原始 LLM 无法执行 shell 命令、跨轮次保持状态、检查文件系统或强制执行安全规则，运行框架为它提供了这些工作条件

由 7 个文件组成的生产级运行框架结构

项目仓库内完整的运行框架目录布局：

.claude/├── CLAUDE.md # Core system instructions and architectural rules├── settings.json # Execution timeouts, budget caps, allowed tools├── hooks/│ ├── pre_tool_hash.py # State hashing hook to prevent redundant file reads│ └── post_tool_audit.py # Execution logging and safety policy enforcer└── memory/ ├── progress.json # State tracking across multi-turn sessions ├── tool_cache.json # Zero-latency tool output cache └── git_checkpoint.log # Rollback log for failed sub-agent branches

CLAUDE.md 系统规范

用于指导运行框架的主要规范文件：

# Repository Architecture Guidelines## Execution Rules- Always run pytest before declaring task completion- Never modify files outside the target subsystem directory- Keep function signatures backwards-compatible## Tool Usage Constraints- Use git status to verify dirty state before editing- Max tool output length: 4000 characters

运行框架状态哈希的 Python 实现

为防止智能体重复读取相同文件、浪费上下文，运行框架会通过状态哈希拦截工具调用：

import hashlibimport jsonimport osCACHE_FILE = ".claude/memory/tool_cache.json"def get_file_hash(filepath: str) -> str: with open(filepath, "rb") as f: return hashlib.sha256(f.read()).hexdigest()def execute_read_file_cached(filepath: str) -> dict: if not os.path.exists(CACHE_FILE): cache = {} else: with open(CACHE_FILE, "r") as f: cache = json.load(f) current_hash = get_file_hash(filepath) cached_entry = cache.get(filepath, {}) if cached_entry.get("hash") == current_hash: return { "content": cached_entry["content"], "cached": True, "tokens_saved": cached_entry["token_estimate"] } with open(filepath, "r", encoding="utf-8") as f: content = f.read() cache[filepath] = { "hash": current_hash, "content": content, "token_estimate": len(content) // 4 } with open(CACHE_FILE, "w") as f: json.dump(cache, f, indent=2) return {"content": content, "cached": False, "tokens_saved": 0}

当智能体在不同轮次之间丢失上下文或读取了错误文件时，应该修复的是运行框架，而不是提示

深入解析：循环层（反馈与证据）
==================

循环规定了系统在模型调用之后要做什么：如何处理工具输出、评估证据，以及决定是否继续

核心原则：围绕证据循环，而不是围绕信心循环

允许智能体一直循环到它声称“我完成了”，会产生充满幻觉的补丁。循环必须要求确定性证据：单元测试通过、代码检查错误为零，以及架构验证通过

[Agent Output] ➔ [Execute Pytest/Linter] ➔ [Pass?] │ ┌─────────────┴───────────────┐ ▼ ▼ [NO: Extract Traceback] [YES: Terminal Pass] │ │ ▼ ▼ [Inject Feedback to Loop] [Return Evidence Signal]

确定性证据循环的实现

这个 Python 模块会执行本地测试验证，并将精简的回溯信息重新送入模型循环：

import subprocessimport sysdef run_evidence_loop(target_file: str, max_retries: int = 3) -> dict: for attempt in range(1, max_retries + 1): linter_result = subprocess.run( ["flake8", target_file], capture_output=True, text=True ) if linter_result.returncode != 0: compact_feedback = f"LINTER ERROR (Attempt {attempt}):\n{linter_result.stdout[:1000]}" print(compact_feedback) continue test_result = subprocess.run( ["pytest", f"tests/test_{os.path.basename(target_file)}"], capture_output=True, text=True ) if test_result.returncode == 0: return { "status": "PASS", "attempts": attempt, "evidence": "All tests passed with zero linter warnings" } compact_feedback = f"TEST FAILURE (Attempt {attempt}):\n{test_result.stdout[-1200:]}" print(compact_feedback) return { "status": "FAIL", "attempts": max_retries, "evidence": "Exceeded maximum retry attempts without passing test suite" }

当智能体输出损坏的代码却宣称成功时，应该修复的是循环

深入解析：图层（流程与并发）
=================

图工程定义控制流：接下来运行哪个节点、工作在哪里拆分为并行任务，以及审批关卡设在哪里

顺序执行智能体（步骤 1 → 步骤 2 → 步骤 3）会造成严重的延迟瓶颈，而图拓扑则能将任务高并发地扇出到多个专业子智能体

┌──► [Sub-Agent A: Scoper] ─────── │ │[Root Task Node] │ │ └──► [Sub-Agent C: Tester]───

异步并行扇出图的实现

这个 Pythonasyncio模块将执行任务扇出为并发的子智能体任务，并在同步关卡汇合结果：

import asynciofrom typing import List, Dictasync def run_sub_agent(agent_id: str, task_scope: str) -> Dict: print(f"Starting Sub-Agent [{agent_id}] for scope: {task_scope}") await asyncio.sleep(1.5) return { "agent_id": agent_id, "status": "SUCCESS", "output": f"Completed analysis for {task_scope}" }async def execute_graph_fan_out(task_prompt: str) -> List[Dict]: sub_tasks = [ ("Agent_Docs", "Search API reference and schemas"), ("Agent_Code", "Scan target refactoring files"), ("Agent_Tests", "Inspect existing unit test coverage") ] tasks = [ run_sub_agent(agent_id, scope) for agent_id, scope in sub_tasks ] results = await asyncio.gather(*tasks) print("Sync Join Gate: All parallel sub-agents completed execution") return resultsif __name__ == "__main__": output = asyncio.run(execute_graph_fan_out("Refactor authentication module")) print(json.dumps(output, indent=2))

当工作以顺序方式而非并发方式运行，或被路由到错误步骤时，应该修复的是图

统一的五阶段主架构
============

将运行框架工程、循环工程和图工程结合起来，可以形成一条统一的自主生产流水线

阶段 01：初始化运行框架沙箱

锁定工作区权限
加载仓库规则（CLAUDE.md）和进度文件
启用工具结果缓存，避免重复消耗 token

阶段 02：并行图扇出与范围界定

根范围界定节点分析提示
将任务扇出到专业子智能体（文档搜索智能体、测试运行智能体、代码编写智能体）
所有子智能体并发执行

阶段 03：由本地证据把关的重试循环

每个节点都运行内部验证循环
代码修改会触发自动代码检查和测试命令
子智能体在本地持续迭代，直到收到测试通过信号

阶段 04：运行框架状态哈希与 token 去重

运行框架跟踪已修改文件的状态哈希
重复读取文件时直接返回缓存的状态哈希，API 延迟和 token 成本均为零

阶段 05：对抗性红队关卡

图将已完成的补丁路由到持怀疑态度的验证节点
验证节点编写边界情况测试，尝试攻破补丁
验证成功后触发 git 提交，并创建生产级 PR

对抗性验证节点的实现
=============

为了确保代码编辑零幻觉，主架构加入了一个对抗性红队验证节点，在创建 PR 之前攻击生成的代码：

def adversarial_red_team_verifier(patch_file: str, test_file: str) -> bool: print(f"Red-Team Node: Auditing generated patch {patch_file}") edge_case_tests = """def test_edge_case_null_input(): result = execute_patched_function(None) assert result is not Nonedef test_edge_case_large_payload(): result = execute_patched_function("A" * 1000000) assert result["status"] == "OK"""" with open(test_file, "a") as f: f.write(edge_case_tests) res = subprocess.run(["pytest", test_file], capture_output=True, text=True) if res.returncode == 0: print("Red-Team Node: Patch passed all adversarial edge-case tests") return True else: print("Red-Team Node: Patch failed adversarial verification") return False

性能基准：实习生模式与主架构
=================

|Metric|Single-Agent Intern Mode|Unified 3-Layer Master Architecture|Improvement Delta|| --- | --- | --- | --- ||Average Task Execution Time|14.2 minutes|2.1 minutes|6.7x faster||Token Spend per PR|$4.80|$0.94|80.4% cost reduction||Test Suite Pass Rate|42%|98.6%|2.3x higher accuracy||Human Escalation Frequency|68% of runs|4% of runs|17x reduction||Hallucinated File Edits|Frequent|Zero|Complete elimination|

反模式与故障诊断
===========

系统故障源于对问题所在层的误判，使用下面的矩阵确定需要修复哪一层：

|Failure Symptom|Underlying Root Cause|Responsible Layer|Corrective Action|| --- | --- | --- | --- ||State lost between sessions|Missing progress file logger|Harness Layer|Implement .claude/memory/progress.json||Agent claims code works but tests fail|Looping on model text assertions|Loop Layer|Enforce deterministic pytest exit codes||Parallel tasks executed sequentially|Single-threaded linear pipeline|Graph Layer|Implement asyncio parallel fan-out nodes||Duplicate token charges for file reads|Uncached tool calls|Harness Layer|Enable SHA-256 file state hashing|

四种主要反模式：

围绕信心循环

依赖模型的文本断言，而不是确定性的测试通过信号

嘈杂的运行框架上下文

将整个代码库塞进提示上下文，而不是使用有针对性的工具调用和状态缓存

不受约束的图循环

构建没有尝试次数上限或升级规则的重试路径

强迫模型处理确定性工作

使用 LLM token 进行字符串解析、去重或文件过滤，而不是使用简单的 Python 脚本

生产就绪检查清单
===========

部署智能体系统之前，请验证以下 5 项要求：

运行框架：权限遵循最小权限原则、工作区在沙箱中运行、文件缓存已启用
循环：停止条件要求提供确定性的测试证据，并强制执行预算上限
图：独立任务并行执行，路由逻辑能够处理错误分支
评估：自动重放真实执行轨迹，对更新进行基准测试
监控：实时跟踪成本、延迟、失败率和人工干预指标

运行框架提供环境，循环提供反馈，图提供流程；统一这三个层，才能构建可靠、可投入生产的 AI 系统

（以上为译文，以下为AI反思）

主流叙事有两个版本：「模型再强一点就够了」和「编排框架才是难点」。真正被硬数据反驳的，是前者的孪生兄弟——人对智能体效果的判断本身系统性失真。METR 在 2025 年做过一次随机对照实验：16 位对自己仓库极其熟悉的资深开源开发者，在真实任务上使用 AI 工具后，完成时间平均慢了 19%；而他们事前预计会快 24%，做完之后仍然认为自己快了约 20%。体感和秒表方向相反，这就是文章里「围绕信心循环 vs 围绕证据循环」在人类层面的版本。这件事极少被公开讨论，是因为没有任何一方有动机说：工具厂商靠体感卖货，为采购签字的管理者已经为体感付过款，开发者本人也不愿意承认自己那种「今天效率好高」的感觉是幻觉。

第二个真相是编排层被系统性高估，而高估它的人恰好是靠它变现的人。2024 年的 Agentless 论文用一条没有智能体、没有图、没有工具调用循环的固定三步流水线（定位 → 修复 → 验证），在 SWE-bench Lite 上超过了当时全部开源智能体方案，单个 issue 成本还低一个量级。同年普林斯顿的《AI Agents That Matter》指出，主流智能体评测只报准确率不报成本，一旦把成本轴画上，许多复杂架构的收益就退化成了「多试几次」。主推复杂图的是以编排为产品的公司（LangGraph、CrewAI、AutoGen 这一类）和需要「自主性」故事去融资的创业团队；有意思的是反对方里站着模型厂商自己——Anthropic 在 2024 年 12 月的《Building Effective Agents》里明确建议先用最简单的方案，并警告框架的抽象层会遮蔽真实的提示词与响应。一家卖模型的公司劝你别用编排框架，这个反常本身就值得盯住。

第三个真相，也是这篇文章刻意绕开的：能不能上智能体，取决于你的仓库，而不是你的智能体。循环层要求确定性证据，而确定性证据是仓库属性——测试跑多久、flaky 率多高、改一行代码能否在 20 秒内拿到 0/1 判决、构建是否可重现。绝大多数企业代码库过不了这一关，于是所谓「证据循环」在现场退化成「跑一遍没红就算过」。这一点几乎没有厂商愿意讲，因为结论是「瓶颈在你自己的工程基建，不在我卖给你的东西」，既不好卖又得罪客户。能公开这么说的，通常只剩内部平台工程师和看账单的财务。

还有一个被忘得很快的案例值得重提：2024 年 3 月 Cognition 的 Devin 演示视频引爆整个行业，一个月后独立开发者逐帧复核其中的 Upwork 片段，发现它修的很大程度上是自己制造出来的问题，且给出的「已完成」结论与实际产物对不上。这不是孤例，而是「演示围绕信心、生产围绕证据」这条分界线最昂贵的一次公开示范。真正的教训不是某家公司夸大了，而是：在没有确定性判决的领域里，演示的说服力与系统的可靠性之间根本不存在相关性。

这类工程师看一个智能体项目，第一秒不看提示词，只找两样东西：状态存在哪里，以及谁有权宣布结束。他们会直接搜停止条件的实现位置——如果停止条件是一次字符串匹配（模型输出里出现了「完成」），后面的架构画得再漂亮也不用往下看了。同理，他们看到「跨轮次丢上下文」时想到的不是「提示词里再强调一遍」，而是「这个进程的状态写在内存里，进程一换就没了」。

他们切片的第一刀沿着「主张 vs 事实」：模型说出来的一切都是主张，进程退出码、文件 diff、编译产物才是事实，系统只允许在事实上做决策。第二刀沿着「确定性 vs 随机性」：能用二十行 Python 完成的字符串解析、去重、过滤，绝不交给 token，因为把确定性工作交给随机过程，等于花钱买方差。第三刀沿着「每轮成本」：他们默认上下文每一轮都在重新计费，所以问的不是「要不要读这个文件」，而是「这个文件读进来之后要在上下文里躺多少轮、被重复购买多少次」。

他们扔掉的假设，恰恰是常人最舍不得扔的几个。扔掉「模型是系统」——在他们眼里模型是系统里最不可靠的那个 RPC，而且错误率不随版本号单调下降。扔掉「自然语言是表达控制流的方式」——控制流交给代码，语言只用来表达意图。扔掉「重试是独立采样」——同一模型、同一上下文的失败高度相关，不改变上下文的重试基本是白烧钱，之所以「把报错贴回去再试一次」有效，起作用的是上下文变了，不是又试了一次。还扔掉了「任务应该被做完」——他们更愿意让系统在预算耗尽时干净地升级给人，而不是体面地继续瞎试。他们的思维模板整体来自 SRE 和分布式系统：幂等、检查点、超时、预算上限、回滚，而不是来自 NLP。

动作一，今晚 30 分钟：翻出你最近三次智能体跑崩的完整会话记录，对每一次失败只允许贴一个标签——环境与状态（框架层）、停止条件（循环层）、顺序与路由（图层），然后统计分布。如果超过一半落在框架层，那么接下来两周你不该改任何一句提示词。这个动作的价值在于它大概率会推翻你的直觉：多数人以为自己在调模型，实际在调环境。

动作二，30 分钟：给你下一个准备交给智能体的任务，先写判决命令，再写提示词。要求是一条能在终端里跑、返回 0 或非 0 的命令。写不出来，就说明这个任务当前不具备可判定性——这个结论本身就是当天最值钱的产出，比硬上智能体划算得多。动作三，20 分钟：给测试套件掐表，如果全量超过 90 秒，就现场造一条只跑受影响文件的子集命令，压到 20 秒以内。循环的迭代速度上限等于你最慢的那道闸门，模型再快也顶不上去。

动作四，15 分钟：打开你最长的那份提示词，对每一条「永远要 / 绝不要」逐条问一句「这能不能改写成一个 hook 或一条 lint 规则」，能的就搬走，然后数一数搬走了几行——那几行原本是你每一轮都在重复付费购买的确定性。动作五，30 分钟：同一个任务、同一份提示词连跑五次，把五份 diff 并排看。如果五次错得几乎一模一样，你现有的重试策略就是在烧钱；如果错得各不相同，重试才真正有意义。这一步给你的是你自己系统的方差数据，任何文章、任何基准表都替不了。

🚨友情提醒：三层框架本身是有价值的思维工具，但这篇文章的形态是内容营销而不是工程报告，最明显的破绽在第 6 节的基准表。6.7 倍、80.4%、98.6%、17 倍这些数字既没有交代任务集，也没有模型版本、样本量、方差和置信区间，而「幻觉文件编辑：零」在原则上就是不可证伪的。真正做过评测的人写不出这种表——真实评测长得很难看，会有失败样例、会有区间、会有「在某些子集上反而更差」。精确到小数点后一位的漂亮数字，功能不是传递信息，而是建立作者权威，后面接的通常是课程、订阅号、咨询或社群。代码是装饰而非实现，这一点逐行读就能确认。证据循环那段的run_evidence_loop里根本没有模型调用：linter 失败时只是 print 然后 continue，所谓「把精简回溯重新送回模型循环」在代码里并不存在，三次重试跑的是完全相同的输入。图层那段的run_sub_agent是一句asyncio.sleep(1.5)的假实现，json和os都没导入。红队节点把边界用例追加写进被测文件之后从不清理，多跑几次测试文件会持续膨胀，而execute_patched_function从头到尾没有定义。这些不是笔误级别的瑕疵，而是「这套东西没有真正完整跑起来过」的痕迹。更值钱的是它没告诉你的几个缺陷。第一，状态哈希缓存省不了它宣称的钱：文件内容一旦进过对话历史，你每一轮都在为它付费，缓存只是避免第二次读盘；真正的省钱手段是提示词缓存（命中时输入价格约为原价一折），而它要求前缀稳定——这套为了去重而不断改写上下文的做法，恰恰会让缓存从改动点起全部失效，优化动作和省钱目标是相反的。第二，并行扇出最难的部分被整个跳过了：三个子智能体在同一个工作树上改文件会互相覆盖，同步汇合点真正要解决的是合并冲突，而示例里的asyncio.gather连这个问题的影子都没有；真做过的人第一件事是给每个子智能体开独立 worktree。第三点最根本：把测试当作真理，前提是测试不由被考核者编写。文章里的红队节点、边界用例，乃至日常修复流程中新增的测试，都可能出自同一个模型。同源的对抗验证只会复现同源的盲区——它擅长确认「我理解的需求被我实现了」，而对「我把需求理解错了」完全无能为力。要让证据循环真正成立，测试的来源必须与实现的来源解耦，这件事没有便宜解法，而全文一个字都没提。作为读者，正确的用法是：拿走三层归因这个诊断框架，扔掉那张基准表和那几段代码。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～