# Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering
**作者**: beamnxw ./
**日期**: 2026-07-25T14:25:13.000Z
**来源**: [https://x.com/beamnxw/status/2081022966645535079](https://x.com/beamnxw/status/2081022966645535079)
---
A practical guide to the three architecture layers people keep mixing together
The confusion is understandable. All three ideas sit around the same model, all three influence reliability, and all three can contain "loops." But they are not synonyms. They describe different engineering decisions, and the distinction matters the moment an agent leaves a demo notebook and starts touching files, APIs, customers, or production code
> THE 30-SECOND ANSWER
- Harness engineering builds the machinery around the model
- Loop engineering designs the repeated work-and-feedback cycle
- Graph engineering makes the workflow topology explicit: nodes, branches, joins, state transitions and controlled cycles
The clean mental model is environment → feedback → flow
# Why these terms suddenly matter
A raw language model cannot create text, maintain a state for a project, run a test suite, look at a browser, enforce an approval rule, or restart a failed job. Those capabilities come from the environment it's in. As agentic software matures, a standard engineering stack is finally coming together. At the foundation is the agent harness, the code that actually runs the models. Next are the loops, which handle the repeating execution and quality checks. Finally, graphs map out the structured paths that guide the entire process
Labels are still not consistently standardized. In the current framework, the term "agent harness" is now starting to take on a rather specific definition. The term "loop engineering" arose as a newer term among practitioners in 2026. Graph engineering should be understood practically rather than as an academic field; it is just the process of creating agent workflows as explicit directed graphs or state machines. This practical distinction is helpful because it prevents a buzzword from hiding the real design question
# Agent Harness Engineering
- According to Langchain, the agent is the model plus the harness, and the harness is the code, configuration and execution logic outside the model. In practice, this includes the system prompt, tool definitions, memory, filesystems, sandboxes, model routing, handoffs, middleware hooks, compaction, permissions, logging and verification interfaces
- OpenAI's Agents SDK describes the same operational core from a runtime perspective: the runner calls the model, executes tool calls, handles handoffs, carries state and stops only when the run reaches a real terminal condition
The word harness is useful because it shifts attention away from model worship. Two teams can use the same foundation model and get very different outcomes because one gives the model clean tools, a stable workspace, constrained permissions and observable state, while the other gives it a vague prompt and an unreliable API wrapper. The intelligence may be similar; the working conditions are not. What a serious harness usually contains:
- Context injection: instructions, retrieved facts, conversation state, skills and task-specific policies
- Action surfaces: APIs, browsers, shells, code interpreters, databases and MCP-compatible tools
- Persistence: files, checkpoints, sessions, progress logs, git history and long-term memory
- Execution control: timeouts, retries, budgets, model routing, sub-agent spawning and approval gates
- Safety and governance: permissions, isolation, allow lists, secret handling and human authorization
- Observability: traces, tool inputs and outputs, state transitions, cost, latency and evaluation results
The model sits inside a wider harness of context, control, action, persistence and verification. Remove the model from your architecture diagram. Everything left is probably part of the harness: the tools, data access, state store, sandbox, middleware, evaluators, retry policy and UI
> Where harness engineering earns its keep
Harness work is important for long-running tasks. In multi-session coding, Anthropic discovered that simply using context compaction was not sufficient. This was not a better prompt by itself, but they made a good setup that created an initializer, a progress file, git history and a discipline of incremental work that each new context can understand what happened and what is still to do. It's an improved working system with regard to the agent. Apply harness engineering when the agent doesn't have a capability, can't come back clean, loses state, accesses too much, can't be audited, or acts differently on environments
# Loop Engineering
Each agent that uses a tool has an embedded small loop:
- call the model
- look at the results
- run the tools
- input observations into the model
- repeat until a final answer is returned
When the builders intentionally build or stack new cycles around that behavior, it is the beginning of loop engineering, as OpenAI calls it. A verification loop, for instance, allows the agent to create an artifact, execute the deterministic check or a grader, receive explicit feedback and repeat only if there are evidence errors. An event-driven loop awakens the agent when a schedule, webhook, or new document is received. An improvement loop analyzes traces & failures, modifies instructions/tools, and tests if the new version works better. LangChain's 2026 framing refers to these as a stack of loops and not one magic while-statement
> The anatomy of a well-engineered loop:
- Trigger: what starts another cycle; user request, schedule, failed test, new data or evaluator feedback
- Goal: a specific state to reach, not a vague instruction to "keep improving"
- State and memory: what the next cycle needs to know without replaying everything
- Action policy: what the agent may change, call, delegate or spend
- Evidence: tests, schema validation, citations, diffs, metrics or human review
- Feedback: a compact, actionable description of why the evidence failed
- Stopping rule: success, budget limit, timeout, irrecoverable error or human escalation
A verification loop wraps the agent loop with an external grader and an explicit pass condition. Do not loop on confidence. Loop on evidence. "The agent says it is done" is not a stopping condition; "the tests pass, the links resolve, the schema validates and the reviewer approves" is.
> Why loop engineering is not just prompt engineering
A prompt tells the model what to do during a call. A loop specifies what the system does after the call:
> how it observes results, chooses feedback, decides whether to continue, persists progress and terminates
Prompt quality still matters, but the loop converts a one-shot instruction into a managed process. The main tradeoff is cost and latency. Each grader, reviewer or retry adds another model call or tool run. Anthropic's broader guidance is to prefer the simplest architecture that works and add agentic complexity only when the performance gain justifies it. The same advice applies to loops: add them where the failure cost is higher than the verification cost
# Graph Engineering
Graph engineering asks a different question though: Not only what the agent does, but what component is permitted to run next. Steps are represented by nodes and allowed steps are represented by edges. These edges can be used to indicate sequence, conditional branching, parallel fan-out, joins, loops and human interrupts. The state traverses the graph, and the topology allows for the desired control flow to be checked. LangGraph is low-level orchestration infrastructure for long-running, stateful agents, with durable execution, state and human-in-the-loop control, and an explicit focus on control over agents rather than an abstraction of the workflow. Microsoft AutoGen's documentation is exceptionally straightforward: use a graph when you need exact control over agent order, different next steps for different outcomes, deterministic branching or complex multi-step processes with cycles. What graph engineers actually decide:
- Node boundaries: which work belongs in a deterministic function, an LLM call, a specialist agent or a human review step
- State schema: what each node may read or update, and how parallel updates are merged
- Routing conditions: which evidence sends work forward, backward, sideways or to escalate
- Concurrency: what can run in parallel, what must join, and what shared resources need coordination
- Cycles and exits: where retries are legal, how many are allowed, and what makes the cycle safe
- Durability: where checkpoints occur and how execution resumes after interruption
The above canvas makes agents, skills and relationships inspectable as a composed system. Graph engineering here means engineering graph-based execution. It is not the same as knowledge graph engineering, where the graph represents entities and relationships in data. A workflow graph represents control and state transitions
> When a graph is worth the ceremony
Graphs are valuable when the process has meaningful branches, parallel work, approvals, recovery paths or multiple specialist agents. They are less useful when the job is simply "give one agent three tools and let it work." A graph can improve debugging, but it can also freeze assumptions too early. If the model must dynamically invent the plan, forcing every possible path into a diagram can make the system more brittle, not less
> How the three layers work together in one real system
Consider a research-and-publishing agent responsible for producing a factual industry briefing
Notice the nesting: the graph runs inside the harness; one or more loops live inside the graph; and the harness supplies the state, tools and evaluators those loops need. The categories overlap because software layers overlap, but each still gives the team a different lever to pull when the system fails
> Choose the engineering layer by diagnosing the failure
# The Expensive Mistakes Behind Weak Agent Architectures
> Building a graph before understanding the work
Teams sometimes translate a business process into dozens of nodes before they have observed how a capable agent actually solves it. Start with traces from a simpler harness, then formalize the stable paths.
> Letting the same model write and grade without safeguards
Self-review can help, but it is vulnerable to shared blind spots. Prefer deterministic checks where possible, separate reviewer context, and require human approval for high-impact actions.
> Using "keep trying" as a loop specification
An unbounded retry loop is a cost leak. Every loop needs a measurable objective, fresh evidence, maximum attempts and a named escalation path.
> Treating the harness as a dumping ground
More tools and memory are not automatically better. A crowded toolset raises selection errors, a noisy context raises confusion, and broad permissions raise risk.
> Blaming the model for orchestration failures
A model cannot compensate reliably for stale state, ambiguous tool schemas, broken APIs or missing exit conditions. Improve the layer that owns the failure.
## A production-ready design checklist
- Harness: Are tools narrow, documented and observable? Is state durable? Are permissions least-privilege? Can operators pause, inspect and resume a run?
- Loop: What evidence proves success? What feedback is returned on failure? How many retries are allowed? What happens when the budget is exhausted?
- Graph: Which paths must be deterministic? Where can work run in parallel? Which state is shared? Where are the human gates and recovery routes?
- Evaluation: Can the team replay real traces, compare versions and attribute improvement to a specific change rather than intuition?
- Operations: Are cost, latency, failure rate, intervention rate and task-level success monitored in production?
## The Simplest Way to Remember the Difference
Engineering something to be a model to make it operate. Loop engineering methodology is iterative, verifiable and resumable. A complex execution path is made explicit and controllable through the use of graph engineering. None of the three is substituted by any of the others. Even if the harness has lost its state, a beautifully drawn graph is no sufficient. However, even with the best harness, if there is no evidence or stop rule, it is a waste of money! Carefully crafted loops are still hard to operate when branching, parallelism and approvals are embedded in the ad-hoc code. If these three layers are designed jointly, reliable agent systems will arise, provided that the team is aware of what each layer is supposed to solve
# SEARCH TERMS READERS USE
- agent harness vs loop engineering
- graph engineering for AI agents
- AI agent orchestration
- LLM agent architecture
- production AI agents
- LangGraph workflows
- AutoGen GraphFlow
- agent verification loops
## Sources and Further Readings
The Anatomy of an Agent Harness - Learn how agent harnesses transform AI models into autonomous work engines. Explore core components: filesystems, sandboxes, and memory
Agents SDK | OpenAI API - Learn how the OpenAI Agents SDK fits together and which docs to read next
LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones - LangChain 1.0 and LangGraph 1.0 are here. Build production-ready AI agents faster with standardized tools, middleware customization, and durable state
GraphFlow (Workflows) - AutoGen - In this section you'll learn how to create an multi-agent workflow using , or simply "flow" for short. It uses structured execution and precisely controls how agents interact to accomplish a task. We'll first show you how to create and run a flow
The Art of Loop Engineering - Agents automate real-world work, but reliable performance requires more than a good model, it requires a carefully designed harness built for specific tasks. This post explores the core agent loop, how stacking and extending loops builds more effective agents, and how to instrument each level with LangChain primitives
Introducing AutoGen Studio from Microsoft Research - AutoGen Studio, built on Microsoft's flexible open-source AutoGen framework for orchestrating AI agents, provides a user-friendly interface that enables developers to rapidly build, test, customize, & share multi-agent AI solutions, with little or no coding
How to Build a Custom Agent Harness - Effective agents are built with harnesses that are tightly coupled with the task at hand. The easiest way to build a custom harness is with LangChain's create_agent plus middleware. This guide covers the core agent loop and how you can customize it for your agent's use case
A practical guide to building agents - A comprehensive guide to designing, orchestrating, and deploying AI agents-covering use cases, model selection, tool design, guardrails, and multi-agent patterns
Building Effective AI Agents - Practical advice and guidance guidance for building production-ready single and multi-agent systems from Anthropic and our customers
Save this so you don't lose it
Follow @beamnxw for more technical posts :)
my telegram channel
## 相关链接
- [beamnxw ./](https://x.com/beamnxw)
- [@beamnxw](https://x.com/beamnxw)
- [66K](https://x.com/beamnxw/status/2081022966645535079/analytics)
- [The Anatomy of an Agent Harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)
- [Agents SDK | OpenAI API](https://developers.openai.com/api/docs/guides/agents)
- [LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones](https://www.langchain.com/blog/langchain-langgraph-1dot0)
- [GraphFlow (Workflows) - AutoGen](https://microsoft.github.io/autogen/stable//user-guide/agentchat-user-guide/graph-flow.html)
- [The Art of Loop Engineering](https://www.langchain.com/blog/the-art-of-loop-engineering)
- [How to Build a Custom Agent Harness](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness)
- [A practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents)
- [Building Effective AI Agents](https://resources.anthropic.com/building-effective-ai-agents)
- [@beamnxw](https://x.com/@beamnxw)
- [my telegram channel](https://t.me/beamnxw11)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:25 PM · Jul 25, 2026](https://x.com/beamnxw/status/2081022966645535079)
- [66.2K Views](https://x.com/beamnxw/status/2081022966645535079/analytics)
- [View quotes](https://x.com/beamnxw/status/2081022966645535079/quotes)
---
*导出时间: 2026/7/26 11:14:45*
---
## 中文翻译
# Agent 挽具工程 vs. 循环工程 vs. 图工程
**作者**: beamnxw ./
**日期**: 2026-07-25T14:25:13.000Z
**来源**: [https://x.com/beamnxw/status/2081022966645535079](https://x.com/beamnxw/status/2081022966645535079)
---
关于人们经常混淆的三种架构层的实用指南
这种混乱是可以理解的。这三个概念都围绕着同一个模型，都影响着可靠性，并且都可以包含“循环”。但它们并不是同义词。它们描述了不同的工程决策，而且当一个 Agent 离开演示笔记本并开始接触文件、API、客户或生产代码时，这种区分就显得尤为重要了。
> 30 秒速览答案
- 挽具工程构建围绕模型的机器
- 循环工程设计重复的工作-反馈周期
- 图工程使工作流拓扑显式化：节点、分支、连接、状态转换和受控循环
清晰的思维模型是环境 → 反馈 → 流程
# 为什么这些术语突然变得重要
原始的语言模型无法创建文本、维护项目的状态、运行测试套件、查看浏览器、执行审批规则或重启失败的任务。这些能力来自于它所处的环境。随着智能体软件的成熟，一个标准的工程栈终于正在成型。基础是 Agent 挽具，即实际运行模型的代码。接下来是循环，用于处理重复的执行和质量检查。最后，图绘制出指导整个过程的结构化路径。
标签的标准尚未统一。在当前的框架下，“Agent 挽具”这一术语正开始呈现出相当具体的定义。“循环工程”一词是 2026 年从业者中新出现的术语。图工程应从实际角度而非学术领域来理解；它只是将 Agent 工作流创建为显式的有向图或状态机的过程。这种实际区分很有帮助，因为它能防止流行语掩盖真正的设计问题。
# Agent 挽具工程
- 根据 LangChain 的说法，Agent 是模型加上挽具，而挽具是模型之外的代码、配置和执行逻辑。实际上，这包括系统提示词、工具定义、记忆、文件系统、沙盒、模型路由、移交、中间件钩子、压缩、权限、日志记录和验证接口。
- OpenAI 的 Agents SDK 从运行时的角度描述了相同的操作核心：运行器调用模型、执行工具调用、处理移交、携带状态，并且仅在运行达到真正的终止条件时才停止。
“挽具”这个词很有用，因为它将注意力从对模型的崇拜上移开。两个团队可以使用相同的基础模型，却得到截然不同的结果，因为一个团队为模型提供了整洁的工具、稳定的工作空间、受限的权限和可观察的状态，而另一个团队只给出了模糊的提示词和不可靠的 API 包装器。智能水平可能相似，但工作条件不同。一个严肃的挽具通常包含：
- 上下文注入：指令、检索到的事实、对话状态、技能和特定于任务的策略。
- 操作面：API、浏览器、Shell、代码解释器、数据库和兼容 MCP 的工具。
- 持久性：文件、检查点、会话、进度日志、Git 历史记录和长期记忆。
- 执行控制：超时、重试、预算、模型路由、子 Agent 生成和审批门控。
- 安全与治理：权限、隔离、允许列表、密钥处理和人工授权。
- 可观测性：追踪、工具输入和输出、状态转换、成本、延迟和评估结果。
模型位于一个更广泛的由上下文、控制、操作、持久性和验证组成的挽具之中。从架构图中移除模型。剩下的所有东西可能都是挽具的一部分：工具、数据访问、状态存储、沙盒、中间件、评估器、重试策略和 UI。
> 挽具工程发挥价值的地方
挽具工作对于长时间运行的任务很重要。在多会话编程中，Anthropic 发现仅使用上下文压缩是不够的。这本身不是更好的提示词，而是他们建立了一个良好的设置，创建了初始化器、进度文件、Git 历史记录和增量工作的规范，使得每个新的上下文都能理解发生了什么以及还有什么要做。这是关于 Agent 的一个改进的工作系统。当 Agent 缺乏某种能力、无法干净地返回、丢失状态、访问过多、无法审计或在不同环境下表现不同时，请应用挽具工程。
# 循环工程
每个使用工具的 Agent 都有一个嵌入的小循环：
- 调用模型
- 查看结果
- 运行工具
- 将观察结果输入模型
- 重复直到返回最终答案
当构建者有意围绕该行为构建或堆叠新的周期时，这就是循环工程的开始，正如 OpenAI 所称的那样。例如，验证循环允许 Agent 创建工件、执行确定性检查或评分器、接收显式反馈，并且仅在存在证据错误时重复。事件驱动循环会在收到计划、Webhook 或新文档时唤醒 Agent。改进循环会分析追踪和失败，修改指令/工具，并测试新版本是否工作得更好。LangChain 2026 年的框架将这些称为一堆循环，而不是一个神奇的 while 语句。
> 一个设计良好的循环的剖析：
- 触发器：什么启动下一个周期；用户请求、计划、失败的测试、新数据或评估器反馈。
- 目标：要达到的特定状态，而不是模糊的“持续改进”指令。
- 状态和记忆：下一个周期需要知道什么，而无需重放所有内容。
- 行动策略：Agent 可能更改、调用、委派或花费什么。
- 证据：测试、模式验证、引用、差异、指标或人工审查。
- 反馈：关于证据失败的紧凑、可操作的描述。
- 停止规则：成功、预算限制、超时、不可恢复的错误或人工升级。
验证循环用外部评分器和显式的通过条件包裹 Agent 循环。不要基于置信度循环。要基于证据循环。“Agent 说它完成了”不是一个停止条件；“测试通过、链接解析、模式验证且审查者批准”才是。
> 为什么循环工程不仅仅是提示词工程
提示词告诉模型在一次调用中做什么。循环指定系统在调用后做什么：
> 它如何观察结果、选择反馈、决定是否继续、持久化进度以及终止
提示词质量仍然很重要，但循环将一次性指令转化为受管理的过程。主要的权衡是成本和延迟。每个评分器、审查者或重试都会增加另一次模型调用或工具运行。Anthropic 的总体指导原则是，首选可行的最简单架构，并且仅在性能提升证明其合理性时才增加 Agent 的复杂性。同样的建议适用于循环：在失败成本高于验证成本的地方添加它们。
# 图工程
然而，图工程提出了一个不同的问题：不仅是 Agent 做什么，而是允许哪个组件接下来运行。步骤由节点表示，允许的步骤由边表示。这些边可用于指示顺序、条件分支、并行分发、连接、循环和人工中断。状态在图中遍历，拓扑结构允许检查所需的控制流。LangGraph 是用于长时间运行、有状态 Agent 的底层编排基础设施，具有持久执行、状态和人工在环控制，并且明确专注于对 Agent 的控制而不是工作流的抽象。Microsoft AutoGen 的文档非常直截了当：当您需要对 Agent 顺序进行精确控制、针对不同结果有不同的后续步骤、确定性分支或带有循环的复杂多步骤过程时，请使用图。图工程师实际决定的内容：
- 节点边界：哪些工作属于确定性函数、LLM 调用、专家 Agent 或人工审查步骤。
- 状态模式：每个节点可能读取或更新什么，以及如何合并并行更新。
- 路由条件：哪些证据将工作向前、向后、向侧面发送或升级。
- 并发性：什么可以并行运行，什么必须连接，以及哪些共享资源需要协调。
- 循环和退出：重试在哪里是合法的，允许多少次，以及什么使循环安全。
- 持久性：检查点在哪里发生，以及中断后如何恢复执行。
上面的画布使 Agent、技能和关系作为一个组合系统变得可检查。这里的图工程意味着基于图的执行工程。它与知识图谱工程不同，后者图表示数据中的实体和关系。工作流图表示控制和状态转换。
> 什么时候图值得这种仪式
当过程有有意义的分支、并行工作、审批、恢复路径或多个专家 Agent 时，图很有价值。当工作仅仅是“给一个 Agent 三个工具并让它工作”时，它们就没那么有用了。图可以改善调试，但也可能过早地冻结假设。如果模型必须动态发明计划，将每条可能的路径强制放入图表可能会使系统更脆弱，而不是更不脆弱。
> 这三层如何在一个真实系统中协同工作
考虑一个负责制作事实性行业简报的研究和发布 Agent。
注意嵌套：图在挽具内运行；一个或多个循环生活在图内；挽具为这些循环提供所需的状态、工具和评估器。类别重叠是因为软件层重叠，但当系统失败时，每个类别仍然给团队提供不同的杠杆可拉。
> 通过诊断失败来选择工程层
# 虚弱 Agent 架构背后的昂贵错误
> 在理解工作之前构建图
团队有时会在观察到能够干的 Agent 实际上如何解决它之前，就将业务流程转化为几十个节点。首先从更简单的挽具的追踪开始，然后规范化稳定的路径。
> 让同一个模型在没有保障措施的情况下编写和评分
自我审查会有所帮助，但它容易受到共同盲点的影响。尽可能首选确定性检查、分离的审查者上下文，并要求对高影响力操作进行人工批准。
> 使用“继续尝试”作为循环规范
无界的重试循环是一个成本漏洞。每个循环都需要一个可测量的目标、新的证据、最大尝试次数和一个命名的升级路径。
> 将挽具当作倾倒场
更多的工具和记忆并不自动意味着更好。拥挤的工具集会增加选择错误，嘈杂的上下文会引起混乱，而广泛的权限会增加风险。
> 将编排失败归咎于模型
模型无法可靠地弥补陈旧的状态、模糊的工具模式、损坏的 API 或缺失的退出条件。改进拥有失败的层。
## 生产就绪的设计清单
- 挽具：工具是否狭窄、有文档记录且可观察？状态是否持久？权限是否最小特权？操作员能否暂停、检查和恢复运行？
- 循环：什么证据证明成功？失败时返回什么反馈？允许多少次重试？预算耗尽时会发生什么？
- 图：哪些路径必须是确定性的？工作可以在哪里并行运行？共享什么状态？人工门控和恢复路线在哪里？
- 评估：团队是否可以重放真实追踪、比较版本并将改进归因于特定更改而不是直觉？
- 运维：成本、延迟、失败率、干预率和任务级成功率是否在生产中受到监控？
## 记住区别的最简单方法
工程化某种东西是为了让模型去操作它。循环工程方法论是迭代的、可验证的和可恢复的。复杂的执行路径通过使用图工程变得显式和可控。这三个都不能被另一个替代。即使挽具丢失了其状态，一张画得很美的图也是不够的。然而，即使有最好的挽具，如果没有证据或停止规则，那就是浪费金钱！当分支、并行性和审批嵌入在临时代码中时，精心制作的循环仍然难以操作。如果这三层共同设计，可靠的 Agent 系统将会出现，前提是团队知道每一层应该解决什么。
# 读者使用的搜索词
- agent harness vs loop engineering
- graph engineering for AI agents
- AI agent orchestration
- LLM agent architecture
- production AI agents
- LangGraph workflows
- AutoGen GraphFlow
- agent verification loops
## 来源和进一步阅读
The Anatomy of an Agent Harness - 了解 Agent 挽具如何将 AI 模型转化为自主工作引擎。探索核心组件：文件系统、沙盒和记忆。
Agents SDK | OpenAI API - 了解 OpenAI Agents SDK 如何组合以及接下来阅读哪些文档。
LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones - LangChain 1.0 和 LangGraph 1.0 来了。使用标准化工具、中间件定制和持久状态更快地构建生产就绪的 AI Agent。
GraphFlow (Workflows) - AutoGen - 在本节中，您将学习如何使用创建多 Agent 工作流，或简称“流”。它使用结构化执行并精确控制 Agent 交互以完成任务。我们将首先向您展示如何创建和运行流。
The Art of Loop Engineering - Agents 自动化现实世界的工作，但可靠的性能不仅需要好的模型，还需要为特定任务精心设计的挽具。这篇文章探索了核心 Agent 循环、如何堆叠和扩展循环以构建更有效的 Agent，以及如何使用 LangChain 原语检测每个级别。
Introducing AutoGen Studio from Microsoft Research - AutoGen Studio 建立在微软用于编排 AI Agent 的灵活开源 AutoGen 框架之上，提供了用户友好的界面，使开发人员能够快速构建、测试、定制和共享多 Agent AI 解决方案，只需很少或无需编码。
How to Build a Custom Agent Harness - 有效的 Agent 是由与手头任务紧密耦合的挽具构建的。构建自定义挽具的最简单方法是使用 LangChain 的 create_agent 加上中间件。本指南涵盖了核心 Agent 循环以及如何为您的 Agent 用例自定义它。
A practical guide to building agents - 设计、编排和部署 AI Agent 的综合指南——涵盖用例、模型选择、工具设计、护栏和多 Agent 模式。
Building Effective AI Agents - 来自 Anthropic 及其客户的关于构建生产就绪的单 Agent 和多 Agent 系统的实用建议和指导。
保存这个以免丢失。
关注 @beamnxw 获取更多技术帖子 :)
my telegram channel
## 相关链接
- [beamnxw ./](https://x.com/beamnxw)
- [@beamnxw](https://x.com/beamnxw)
- [66K](https://x.com/beamnxw/status/2081022966645535079/analytics)
- [The Anatomy of an Agent Harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)
- [Agents SDK | OpenAI API](https://developers.openai.com/api/docs/guides/agents)
- [LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones](https://www.langchain.com/blog/langchain-langgraph-1dot0)
- [GraphFlow (Workflows) - AutoGen](https://microsoft.github.io/autogen/stable//user-guide/agentchat-user-guide/graph-flow.html)
- [The Art of Loop Engineering](https://www.langchain.com/blog/the-art-of-loop-engineering)
- [How to Build a Custom Agent Harness](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness)
- [A practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents)
- [Building Effective AI Agents](https://resources.anthropic.com/building-effective-ai-agents)
- [@beamnxw](https://x.com/@beamnxw)
- [my telegram channel](https://t.me/beamnxw11)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:25 PM · Jul 25, 2026](https://x.com/beamnxw/status/2081022966645535079)
- [66.2K Views](https://x.com/beamnxw/status/2081022966645535079/analytics)
- [View quotes](https://x.com/beamnxw/status/2081022966645535079/quotes)
---
*导出时间: 2026/7/26 11:14:45*