一、引言
AI Agent 的关键能力来自一个持续运行的反馈循环：系统先理解任务和约束，再选择下一步行动；如果行动需要外部能力，就调用工具并读取环境返回的结果；如果结果不符合预期，就修正计划或操作；直到任务完成、达到停止条件，或者需要把决策权交还给用户。
本文将这个过程抽象为六个阶段：
输入理解 → 任务规划 → 工具执行 → 结果观察 → 错误修正 → 最终响应
↑ |
+-------------------------+
这个六阶段模型不一定对应六次模型调用，一个模型响应可能同时完成输入理解、局部规划和工具选择；一个框架节点也可能把观察与纠错合并。这里划分的是逻辑职责，而不是固定的代码模块。
它是一种工程抽象，不是行业统一标准。它的价值在于提供共同语言：无论系统采用 OpenAI Agents SDK、LangGraph、Google ADK，还是自研 Runtime，都可以用同一组问题分析其执行链路。
二、输入理解：把自然语言转成可执行任务
用户输入通常只描述期望，没有完整描述执行条件。例如：
帮我分析线上支付失败的原因，并给出修复建议。
Agent 在执行前至少需要提取以下信息：
Task
├── Goal：定位支付失败原因并提出修复建议
├── Scope：线上支付链路
├── Constraints：不能直接修改生产环境
├── Required evidence：日志、指标、发布记录、错误栈
├── Completion criteria：原因有证据支持，建议能对应原因
└── Missing information：时间范围、服务名称、环境权限
1.输入理解不是关键词分类
可靠的输入理解至少包含四个维度：
2.事实与假设需要分开
可以把 Agent 初始状态表示为：
State = {
observations: 已知事实,
assumptions: 当前假设,
constraints: 操作边界,
open_questions: 尚未解决的问题,
artifacts: 已获取的外部结果
}
“支付失败发生在数据库层”在读取错误栈之前只能算假设。如果 Agent 把假设当作事实，后续规划会沿错误方向持续展开。
3.歧义处理也是一种行动
遇到关键信息缺失时，Agent 有三个选择：
低风险、可撤销 -> 采用显式假设后继续
可通过只读工具获得 -> 调用工具补充信息
高风险或不可推断 -> 请求用户澄清或批准
请求澄清并不意味着 Agent 失败。对于删除数据、发送消息、部署生产环境等高影响操作，把控制权交还给用户是正确的运行时决策。
三、任务规划：规划的是下一步，不一定是完整路线
任务规划容易被理解成“一开始生成一份完整步骤列表”。这种做法只适合环境稳定、路径可预测的任务。
真实环境会持续暴露新信息。Agent 更适合使用滚动规划：
初始目标
|
v
规划当前最合理的一步
|
v
执行并获取新信息
|
v
更新状态和剩余任务
|
+----> 规划下一步
1.三种常见规划粒度
- 反应式规划：每轮只确定下一步。
观察日志为空
-> 检查日志时间范围
发现时区错误
-> 修正查询参数
发现数据库超时
-> 查询数据库指标
优点是能适应环境变化，缺点是容易短视或重复探索。
- 分层规划：先生成里程碑，再动态选择每个里程碑内的行动。
目标：定位支付失败
├── 1. 确认故障窗口
├── 2. 定位异常服务
├── 3. 验证候选原因
└── 4. 形成修复建议
分层规划兼顾方向稳定和局部灵活性，适合多数工程 Agent。
- 固定工作流：由程序预先定义执行路径。
输入分类 -> 参数校验 -> 查询数据库 -> 生成报告
它的行为容易测试，适合步骤明确的业务流程。路径已知时应优先考虑 workflow；无法预知步骤、需要模型动态决策时才使用 agent。
2.好计划需要包含验证动作
弱计划只描述“做什么”：
1. 搜索代码
2. 修改代码
3. 返回结果
可验证计划同时描述“如何知道做对了”：
1. 搜索错误码的定义和调用路径
验证：找到错误码的产生位置和传播链路
2. 根据失败条件修改最小范围代码
验证：变更只影响目标分支
3. 运行相关测试
验证：原失败用例通过，相关回归用例未失败
缺少验证步骤时，Agent 很容易把“工具调用成功”误判为“任务成功”。
四、工具执行：模型提出调用，运行时负责落地
模型通常不会直接执行外部操作。它生成结构化的工具调用请求，由 Runtime 校验并分派。
LLM 输出
{
"tool": "search_logs",
"arguments": {
"service": "payment-api",
"start_time": "2026-10-26T09:00:00+08:00",
"query": "status:error"
}
}
|
v
Runtime 校验
├── 工具是否存在
├── 参数是否符合 Schema
├── 当前身份是否有权限
├── 是否需要人工批准
└── 是否达到调用预算
|
v
工具适配器
|
v
日志平台 / 数据库 / 浏览器 / Shell / 内部 API
1.工具接口是 Agent 的行动空间
对 Agent 来说，工具名称、描述和参数 Schema 共同定义了它可以采取哪些行动。下面两个接口实际能力相近，但对模型的可用性不同：
//第一种
run(command: string)
//第二种
search_logs(
service: string,
start_time: datetime,
end_time: datetime,
query: string
)
后者明确表达了参数边界，运行时也能进行结构化校验。工具接口也称为 Agent-Computer Interface，其工具文档与测试会直接影响 Agent 表现。
2.工具错误需要机器可读
只有一段模糊文本：
Error: operation failed
模型很难决定下一步。结构化错误更有利于恢复：
{
"status": "error",
"code": "TIME_RANGE_TOO_LARGE",
"message": "单次查询最多支持 24 小时",
"retryable": true,
"suggestion": "缩小时间范围或拆分查询"
}
其中最关键的是：
- code ：稳定的错误分类；
- retryable ：是否值得重试；
- suggestion ：允许怎样调整；
- details ：供诊断使用的原始信息；
- side_effect ：失败前是否已经产生部分副作用。
3.有副作用的工具需要不同控制
工具可以按风险分层：
L0 纯计算：格式转换、数学计算
L1 只读访问：搜索、读取文件、查询日志
L2 可撤销写入：创建草稿、修改工作区文件
L3 外部副作用：发消息、创建工单、调用付费服务
L4 高影响操作：删除数据、生产部署、资金操作
风险越高，越需要参数约束、幂等键、权限隔离、审批和审计记录。Agent 的智能水平不能替代这些系统控制。
五、结果观察：工具返回值还不是结论
ReAct 的核心贡献之一，是让模型交错地产生推理和行动，并将环境观察用于后续决策。在工程实现中，“观察”是把工具原始返回转成可以更新 Agent 状态的信息。
工具原始结果
|
v
语法检查：返回格式是否完整
|
v
语义检查：结果是否回答当前子问题
|
v
状态更新：新增了哪些事实和证据
|
v
进度判断：目标是否更接近完成
假设日志工具返回了 200 条记录。Agent 不应只记录“查询成功”，而应提取：
Observation
├── 事实：09:31 后失败率由 0.2% 升至 18.4%
├── 事实：错误集中为 DB_CONNECTION_TIMEOUT
├── 关联：09:28 有数据库配置变更
├── 缺口：尚未证明配置变更导致连接超时
└── 下一验证：对照连接池指标和变更内容
工具成功描述的是调用状态，任务成功描述的是目标状态。两者必须分开。
另外，观察信息需要进入共享状态。LangGraph 把 state 描述为所有节点都能访问的共享记忆，用来保存跨步骤仍需保留的信息；其图节点读取状态并返回状态更新，这种设计可以防止执行逻辑依赖零散字符串拼接。
一个实用状态结构可以包含：
AgentState
├── user_goal
├── constraints
├── plan
├── observations[]
├── tool_calls[]
├── verified_facts[]
├── hypotheses[]
├── unresolved_questions[]
├── retry_budget
└── status
状态不应无限增长。长任务需要摘要、裁剪或外部存储，否则上下文成本会持续增加，旧信息也可能干扰当前判断。
六、错误修正：从失败中获得可用信号
Agent 的错误修正可以分成四层。
- 调用级错误：包括参数缺失、类型错误、超时、限流和权限不足，这类错误通常不需要重新规划整个任务。
参数错误 -> 修正参数后重试
临时超时 -> 有上限地退避重试
权限不足 -> 请求授权或更换只读路径
工具不存在 -> 选择可用工具
- 结果级错误：工具正常返回，但结果不可用，这要求 Agent 检查结果语义，而不是只看 HTTP 状态码或进程退出码。
搜索结果为空
测试命令退出码为 0，但没有运行任何测试
网页请求成功，但内容是登录页
数据库查询成功，但使用了错误时间范围
- 计划级错误：连续几个步骤都没有减少不确定性，说明当前路线可能错误，有效修正需要改变假设、工具、查询范围或任务分解。如果 Agent 使用相同参数机械重试，它只是在消耗预算。
假设 H1
|
+-> 查询 A：无证据
|
+-> 查询 B：无证据
|
+-> 查询 C：仍无证据
|
v
放弃或降低 H1 优先级，生成 H2/H3
- 目标级错误：Agent 发现原目标无法在当前条件下完成，例如：用户要求访问未授权系统、数据源缺失而无法得出确定结论、两个约束互相冲突、执行风险超过允许范围等，此时正确行为是停止，说明证据、缺口与可选路径，而不是编造结果。
反思并不等于重新训练模型，错误修正可以发生在推理时状态和记忆层，通过语言形式的反馈，让 Agent 总结错误并把反思文本保存在情景记忆中，以影响后续尝试，而不需要更新模型权重。
不过，自我反思不能代替外部验证。模型可能生成听起来合理、实际错误的批评。工程系统应优先使用测试结果、API 响应、规则校验器和人工反馈等外部信号。
七、最终响应：用证据证明任务结束
Agent 不应因为“感觉已经完成”而停止。停止条件通常来自四类信号：
┌─────────────────┬──────────────────────────────────────┐
│ 停止类型 │ 条件 │
├─────────────────┼──────────────────────────────────────┤
│ 成功结束 │ 完成标准满足，必要证据已获得 │
│ 受控失败 │ 关键条件缺失，继续执行无法推进 │
│ 等待用户 │ 需要澄清、授权、审批或主观判断 │
│ 预算终止 │ 达到最大轮数、时间、费用或调用上限 │
└─────────────────┴──────────────────────────────────────┘
一个可靠的最终响应通常包括：
- 完成了什么；
- 关键结论是什么；
- 使用了哪些证据；
- 哪些内容尚未确认；
- 是否产生了外部副作用；
- 用户接下来是否需要做决定。
结论：
支付失败由连接池上限配置错误引起。
证据：
- 09:28 发布将 max_connections 从 200 调整为 20；
- 09:31 起连接等待时间和支付失败率同步上升；
- 回滚配置后，测试环境的失败用例恢复通过。
已执行：
- 修改测试环境配置；
- 运行支付服务集成测试，42 个用例全部通过。
未执行：
- 未修改生产环境，生产回滚仍需审批。
这种响应保留了结果、证据和操作边界，比一句“问题已经修复”更适合审计。
八、把六阶段闭环写成最小 Runtime
下面的伪代码省略了模型供应商和工具协议细节，保留 Agent Runtime 的核心结构：
def run_agent(user_input, tools, limits):
state = initialize_state(user_input)
turns = 0
while turns < limits.max_turns:
turns += 1
model_input = build_context(
goal=state.goal,
constraints=state.constraints,
plan=state.plan,
observations=state.observations,
available_tools=tools.schemas(),
)
decision = call_model(model_input)
if decision.type == "final":
if completion_check(decision.output, state):
return success(decision.output, state)
state.observations.append({
"type": "validation_error",
"message": "最终输出尚未满足完成标准",
})
continue
if decision.type == "ask_user":
return waiting_for_user(
question=decision.question,
resumable_state=state,
)
if decision.type == "tool_call":
validation = validate_tool_call(decision, tools, state)
if not validation.ok:
state.observations.append(validation.error)
state = revise_plan(state)
continue
result = tools.execute(
name=decision.tool_name,
arguments=decision.arguments,
)
observation = normalize_tool_result(result)
state.observations.append(observation)
if observation.indicates_failure:
state = repair_or_replan(state, observation)
else:
state = update_progress(state, observation)
return stopped(
reason="max_turns_exceeded",
state=state,
)
这个循环包含几个不可省略的控制点：
模型调用前：构建受控上下文
工具执行前：校验工具、参数、权限和审批
工具执行后：规范化结果并更新状态
最终回答前：检查完成条件
每轮结束后：检查预算和停止条件
真实系统还需要增加持久化、并发控制、幂等性、事件流、可观测性和人工介入机制。它们不会改变闭环本身，只会让闭环在生产环境中更可靠。
九、用统一模型分析不同 Agent 框架
十、分析一个 Agent 系统的七个问题
面对一个新的 Agent 框架或产品，可以沿以下顺序分析：
1. Goal
用户目标怎样进入系统？
2. State
哪些信息会跨步骤保存？
3. Policy
谁决定下一步，模型、规则还是两者共同决定？
4. Action
Agent 可以调用哪些工具，工具怎样描述？
5. Observation
工具结果怎样返回并更新状态？
6. Recovery
参数错误、工具失败和计划失败分别怎样处理？
7. Termination
谁判断任务完成，最大预算是多少？
进一步可以增加两个生产问题：
8. Control
哪些操作需要审批、隔离或人工接管？
9. Observability
能否追踪模型输入、工具参数、结果、状态变化和停止原因？
如果一个系统只能回答 Action，却无法清楚解释 State、Recovery 和 Termination，它通常只是“支持工具调用的聊天应用”，还没有形成可靠的 Agent Runtime。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Introduction
AI Agent ' s key capabilities are derived from a continuous feedback cycle: the system understands tasks and constraints before selecting next step actions; calls tools and reads the results of environmental returns if the operation requires external capabilities; revises the plan or operation if the outcome does not meet expectations; until the mission is completed, the conditions for cessation are met, or the decision-making authority is returned to the user.
The process is abstracted into six phases:
Input Understanding → Task Planning → Tool Implementation → Results Observation → Error correction → Final sound Response
↑ |
+-------------------------+
This six-stage model does not necessarily correspond to six calls, and a model response may simultaneously complete input understanding, local planning and tool selection; a framework node may also combine observations with errors. Here, logical responsibilities are divided rather than fixed code modules.
It is a engineering abstraction, not a uniform industry standard. Its value lies in providing a common language: whether the system uses Open AI Agents SDK, LangGraph, Google ADK or self-study Runtme, it can analyse its implementation links using the same set of questions.
II. INTEGRATION UNDERSTANDING: TRANSFER OF NATURAL LANGUAGES TO CAPACITY
User input usually only describes expectations and does not provide a complete description of the conditions of execution. For example:
Help me analyze the reasons for the failure of online payments and give recommendations for repairs.
Agent needs to extract at least the following information before execution:
Task
Ideas - Goal: Identifying the causes of the failure and recommending repairs
-Scope: Online payment chain
Ideas - Constraints: Can't modify the production environment
Ideas-Required evidence: logs, indicators, publish records, error cages
Ideas - Decision crime: the reason is supported by evidence and the recommendation is reciprocated.
- Missing information: time frame, service name, environment permission
1. Input understanding is not a keyword classification
A reliable input understanding contains at least four dimensions:
2. The need to separate facts from assumptions
The initial state of Agent can be expressed as:
State = {
#Observations: Known facts
This post is part of our special coverage Syria Protests 2011.
Operating the boundary,
Open questions: Unsolved issues
External results obtained
}
“Pay failures occur at the database level” and can only be assumed before reading the error stack. If Agent took the assumption as a fact, subsequent planning would continue in the wrong direction.
3. Discriminating is also an action.
When key information is missing, Agent has three options:
Low risk, avoidable - > Continue with a visible assumption
Additional information via read-only - > Call Tool
High risk or non-inference - > Request for clarification or approval from user
The request for clarification does not mean that Agent failed. For high-impact operations such as deleting data, sending messages and deploying production environments, returning control to the user is the right running time decision.
III. Mission planning: next step is planned, not necessarily a complete route
Mission planning is easily understood as “producing a complete list of steps at the outset”. Such an approach would be appropriate only for environmentally stable and predictable tasks.
The real environment continues to expose new information. Agent is better suited for rolling planning:
Initial target
|
v
Planning the most logical step of the day
|
v
Execute and access new information
|
v
Update status and remaining tasks
|
+ Planning next step
1. Three common planned particles
- Responsive planning: Only next step is identified per round.
Watch Log is empty
- Check the log time frame.
Time zone error detected
->Correct query parameters
Found database timeout
- >Query database indicators
The advantage is that it adapts to environmental change, and the disadvantage is that it is easy to look short or duplicate.
- Sequenced planning: Mr. Señor is a milestone and then dynamically selects actions within each milestone.
Target: Failed to locate payment
Ideas - 1. Identification of malfunction windows
Ideas - 2. Positioning Abnormal Services
3. Validation of candidates
└4 form the restoration proposal
The stratification plan combines directional stability and local flexibility and is suitable for most projects, Agent.
- Fixed workflow: Predefined execution path by program.
Enter Category - > Parameter Verify - > Query Database - > Generate Report
Its behaviour is easily tested and suited to clear business processes. When the path is known, preference should be given to workflow; it is impossible to predict steps and requires dynamic model decision-making before using an agent.
Good plans need to include authentication actions
Weak plans only describe what to do:
1. Search codes
2. Revision of codes
3. Return results
The certification scheme also describes “how to know what to do right”:
1. Definition of search error codes and call paths
Authentication: Found the creation of the wrong code and the transmission links
2. Change the minimum range code to the failure condition
Validation: Change affects target branch only
3. Operation of relevant tests
Authentication: the original failure was passed and the relevant return was not unsuccessful
In the absence of validation steps, Agent can easily misjudge “tool call success” as “mission success”.
IV. Tools implementation: Models are proposed for call and run on land
Models usually do not perform external operations directly. It generates structured tool call requests, verified and assigned by Runtime.
LLM Output
{
"tool": "search_logs",
"arguments": {
"service": "payment-api",
"start_time": "2026-10-26T09:00:00+08:00",
"query": "status:error"
}
}
|
v
Runtme Verify
Ideas — Do tools exist?
Ideas - Parameters Fit to Schema
Does the current identity have permission?
Idea-- Do you need manual approval?
└ - Has reached the call budget
|
v
Tool Adapter
|
v
Log Platform / Database / Browser / Shell / Internal API
1. Tool interface is the action space for Agent
For Agent, the name, description and parameters of the tool Schema define what it can do. The following two interfaces have similar physical capabilities, but the availability of models varies:
First
run(command: string)
/ Second
search_logs(
service: string,
start_time: datetime,
end_time: datetime,
query: string
)
The latter is a clear expression of the parameters boundary, which can also be run in a structured manner. Tool interfaces are also known as Agent-Computer Interface, whose tool files and tests directly affect Agent performance.
2. Tool error requires machine readability
There is only one vague text:
Error: operation failed
The model is hard to determine. Structural errors are more conducive to recovery:
{
"status": "error",
"code": "TIME_RANGE_TOO_LARGE",
"Message": "A single query supports a maximum of 24 hours,"
"retryable": true,
"suggestion": "Shrink the time frame or split queries"
}
The most critical of these are:
- Code: stable error classification;
- Retryable: Is it worth retry;
- Suggestion: how to allow adjustments;
- Destails: raw information for diagnostic purposes;
-side effect: Has partial side effects occurred before failure.
3. Tools with side effects require different controls
Tools can be layered by risk:
L0 pure calculation: format conversion, mathematical calculation
L1 Read-only access: search, read files, query logs
L2 Unable to write: create drafts, modify workspace files
L3 External side effects: sending messages, creating worksheets, calling paid services
L4 High-impact operations: delete data, production deployment, financial operations
The higher the risk, the greater the need for parameters constraints, keys, permission isolation, approval and audit records. Agent 's intelligence level is not a substitute for these system controls.
Results observation: return value of tools is not yet a conclusion
One of the core contributions of Rect is to stagger models into reasoning and action and to use environmental observations for subsequent decision-making. In the course of the project, “observation” is the return of the original tool to information that will update the Agent state.
Original tool result
|
v
Syntax: Revert full format
|
v
Semantic examination: the result answers the current sub-question
|
v
Status update: What new facts and evidence have been added
|
v
Progress judgement: is the target closer to completion
Assuming that the log tool returns 200 records. Agent should not simply record “successful queries” but should extract:
Observation
Idea - Fact: 09:31 after failure rate rose from 0.2% to 18.4%.
Ideas — Facts: Errors focused on DB CONNECTION TIMEOUT
Idea - Association: 09:28 Database configuration changes
Idea-- Gap: No change of configuration leading to timeout
└ Next validation: against connect pool indicators and changes in content
The tool successfully describes the call state and the mission successfully describes the target state. The two must be separated.
In addition, observational information needs to be shared. LangGraph describes the state as a shared memory that can be accessed by all nodes and is used to preserve information that remains to be kept across the steps; its node reads the state and returns the status update, a design that prevents the execution logic from relying on a piecemeal string.
A functional state structure could include:
AgentState
├── user_goal
├── constraints
├── plan
├── observations[]
├── tool_calls[]
├── verified_facts[]
├── hypotheses[]
├── unresolved_questions[]
├── retry_budget
└── status
The state of affairs should not grow indefinitely. Long missions require summary, tailoring or external storage, otherwise context costs will continue to increase and old information may interfere with current judgement.
Error correction: obtaining a signal from failure
Agent 's error correction can be divided into four layers.
- Call error: including missing parameters, type errors, inadequate timeout, rate limit and permission, such errors usually do not require a reprogramming of the entire task.
Parameter Error - > retry after correction
Temporary timeout - retry with ceilings.
permission is inadequate - > Request permission or change read-only path
Tools do not exist - > Choose Available Tools
- Result level error: the tool returns normally, but the result is not available, which requires Agent to check the semantics of the result instead of looking only at the HTTP status code or process exit code.
Search result is empty
Test command exit code 0, but no tests run
Web request successful, but content is login page
Database queries were successful, but error time frames were used
- Errors at the planning level: successive steps have not reduced uncertainty, suggesting that the current route may be wrong and that effective amendment requires changes in assumptions, tools, scope of queries or task breakdown. If Agent uses the same parameters as the machine retry, it's just consuming the budget.
Hypothetical H1
|
+- Query A: No evidence
|
+- Query B: No evidence
|
+- Query C: Still No Evidence
|
v
Drop or lower H1 priority, generate H2/H3
- Error at target level: Agent found that the original target could not be achieved under current conditions, e.g. user requests for access to unauthorized systems, missing data sources that could not reach definitive conclusions, conflicting constraints, risk of implementation exceeding permissible limits, etc., at which point the correct behaviour was stopped, indicating evidence, gaps and optional paths, rather than fabricated results.
Rethinking is not tantamount to retraining the model, and the error correction can take place in the state and memory of reasoning, with feedback in the language, allowing Agent to summarize the error and keep the reflection text in the scenario memory to influence subsequent attempts without having to update the model ' s weight.
However, self-reflection cannot be a substitute for external validation. Models can generate criticism that sounds reasonable and actually wrong. Engineering systems should prioritize the use of external signals such as test results, API responses, rule-checkers and manual feedback.
Final response: proof of end of mission
Agent should not be stopped by “the feeling is complete”. The conditions for cessation usually come from four types of signals:
┌─────────────────┬──────────────────────────────────────┐
│ Stop type │ Conditions │
├─────────────────┼──────────────────────────────────────┤
♪ Successfully done ♪
♪ Controlled failure ♪
Waiting for users │ Needing clarification, authorization, approval or subjective judgement │
Budget termination Maximum number of rounds, time, cost or call ceiling
└─────────────────┴──────────────────────────────────────┘
A reliable final response usually includes:
- Finish what?
- What are the key conclusions;
- What evidence is used;
- What has not yet been identified;
- Whether external side effects have occurred;
- Whether the user needs to decide next.
Conclusions
The payment failed due to an error in the configuration of the connect pool ceiling.
Evidence:
- 09:28 publish adjusts max conventions from 200 to 20;
- 09:31 The waiting time for connection and the failure rate for payment are rising simultaneously;
- After rolling back into the configuration, the failure of the test environment is restored by example.
Implemented:
- Modification of the test environment configuration;
- Run payment service integration tests, all 42 examples passed.
Not implemented:
- No changes have been made to the production environment and the rollback of production is still subject to approval.
This response retains results, evidence and operational boundaries and is more suitable for audit than a phrase “the problem has been repaired”.
VIII. Minimum six-stage closed loops
The following pseudocode omits details of model suppliers and tool protocols and retains the core structure of Agent Runte:
def run_agent(user_input, tools, limits):
state = initialize_state(user_input)
turns = 0
while turns < limits.max_turns:
turns += 1
model_input = build_context(
goal=state.goal,
constraints=state.constraints,
plan=state.plan,
observations=state.observations,
available_tools=tools.schemas(),
)
decision = call_model(model_input)
if decision.type == "final":
if completion_check(decision.output, state):
return success(decision.output, state)
state.observations.append({
"type": "validation_error",
"Message": "Final output does not meet completion criteria."
})
continue
if decision.type == "ask_user":
return waiting_for_user(
question=decision.question,
resumable_state=state,
)
if decision.type == "tool_call":
validation = validate_tool_call(decision, tools, state)
if not validation.ok:
state.observations.append(validation.error)
state = revise_plan(state)
continue
result = tools.execute(
name=decision.tool_name,
arguments=decision.arguments,
)
observation = normalize_tool_result(result)
state.observations.append(observation)
if observation.indicates_failure:
state = repair_or_replan(state, observation)
else:
state = update_progress(state, observation)
return stopped(
reason="max_turns_exceeded",
state=state,
)
This cycle contains several control points that cannot be omitted:
Model before call: Build controlled context
Pre-implementation: validation tools, parameters, permission and approval
After the tool is implemented: regularize and update the status
Before final answer: Check completion conditions
At the end of each round: inspection of the budget and conditions of cessation
Real systems also need to be made more durable, co-control, muscular, event flow, observable and manual intervention mechanisms. They do not change the rings themselves, but only make them more reliable in the production environment.
Analysis of differences with uniform models
X. Analysis of the seven issues of an Agent system
A new Agent framework or product can be analysed in the following order:
1. Goal
How do user targets get into the system?
2. State
What information will be stored in steps?
3. Policy
Who decides next step, models, rules or both?
4. Action
What tools can Agent call and what tools can he describe?
5. Observation
How does the tool result return and update the status?
6. Recovery
How are parameter errors, tool failures and plan failures dealt with separately?
7. Termination
Who judges what is the maximum budget for a mission?
Two additional production issues could be added:
8. Control
What operations require approval, isolation or manual takeover?
9. Observability
Can model inputs, tool parameters, results, state changes and reasons for discontinuation be tracked?
If a system can only answer Action, but it cannot clearly explain State, Recovery and Termination, it is usually simply “a chat application that supports tool call” and has not yet produced a reliable Argentina.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.