跳到正文
DEV Community· Conor Bronsdon·· 3 小時前AI 評分64

可投入使用的最小智能體循環,以及何時應跳過

The Minimum Agent Loop You Can Ship (and When to Skip It)

AI 導讀

Conor Bronsdon 提出一套可投入使用的最小智能體循環,由模型、工具、循環和停止條件四部分構成。步驟及順序預先確定時,應用固定工作流程;若步數取決於用戶目標或工具輸出,且模型需按中間結果選擇工具,則可用循環。循環需設明確停止條件並限制步數;接近正式環境時,評估應從第一天開始,並記錄每步的索引、工具名稱和延遲。

正文

Most "agents" in production are a loop: the model picks a step, calls a tool, reads the result, and decides whether to stop. Name that loop and its stop condition before you call the thing an agent.

An AI agent is given a goal and runs until the goal is met or it gives up. A chatbot takes a prompt and returns a response. A bigger model does not turn one into the other. The system around the model does: tools, state, and something that decides "one more step" versus "done." Vikram Chatterji described that 2025 shift as generative AI moving from chat completion toward actual task completion.

What belongs in the smallest useful loop?

I'd start with four pieces only:

  1. Model: produces the next intent (tool name and arguments, or a final answer).
  2. Tools: functions that fetch data or have real side effects (search, SQL, creating a ticket).
  3. Loop: append tool results to state, call the model again.
  4. Stop condition: max steps, an explicit finish tool, or a terminal field such as done: true in the model's JSON.

Memory, multiple models and evals come next, and if production is close, evals belong on day one. Aishwarya Srinivasan frames the shift well: production agents are software systems to architect, and a benchmark winner alone will not get you there.

The following is a sketch (not production code, no real SDK):

# Sketch: minimum agent loop (illustration only)
from typing import Any, Callable

MAX_STEPS = 8
tools: dict[str, Callable[..., Any]] = {
    "search_docs": lambda q: f"results for {q}",
    "finish": lambda answer: {"answer": answer},
}

def run_agent(goal: str) -> str:
    messages = [{"role": "user", "content": goal}]
    for step in range(MAX_STEPS):
        plan = model_next(messages)  # your LLM wrapper
        if plan.get("type") == "final":
            return plan["text"]
        name, args = plan["tool"], plan.get("args", {})
        if name not in tools:
            messages.append({"role": "tool", "content": f"unknown tool: {name}"})
            continue
        result = tools[name](**args)
        messages.append({"role": "tool", "name": name, "content": str(result)})
        if name == "finish":
            return str(result)
    return "stopped: max steps"

That is the operational shape of an agentic workflow: chained decisions toward a goal, with the model choosing the next move inside bounds you set.

How does this relate to ReAct?

ReAct (Reason + Act) interleaves reasoning with one action at a time: reason, act, observe, repeat. Your sketch does not need the model to print long reasoning traces, but the control flow is the same. The model does not plan the full path up front; it reacts to what came back from the last tool call.

That adaptability has a cost. In a reason-act loop, an agent with incomplete context can keep firing queries against data it cannot access, without ever reasoning its way to "I can't answer this." Before you widen tool access, tighten the stop rules and cap steps. Autonomy without bounds is how you get runaway tool and query volume.

When should I use a loop instead of a fixed workflow?

Use a fixed workflow (scripted steps, deterministic branches) when:

  • The path is known before runtime (same steps, same order, every time).
  • Mistakes are cheap and easy to undo.
  • You can test every branch without the model inventing new ones.

Use the minimum loop when:

  • The number of steps depends on the user's goal or on tool output you cannot predict.
  • The model must choose among several tools based on intermediate results.
  • You are okay trading predictability for flexibility, and you will add checks later.

Do not reach for a loop because "agents" are the product story. Reach for it when a single prompt or a rigid pipeline cannot reach the goal without repeated tool use. Most shipping teams let the model decide within bounded steps, with guardrails and evaluation at each stage, rather than running a free agent. That middle ground is where a lot of practical building on AI agents actually lives.

What do I add after the loop runs once?

The canonical "chatbot to agent" stack names four production layers beyond the loop itself: orchestration across models, memory and context, tools, and evals with guardrails. The loop is the engine; those layers are how it stays trustworthy.

For builders stepping from demos to systems, Aishwarya Srinivasan's line is the guardrail I keep in mind:

It is not a model that you are surfacing to your user. It is a software. It is a system that you're surfacing to your user

Aishwarya Srinivasan, Fireworks AI, on Chain of Thought ep 42

Her production rule from the same conversation theme: quantify each step so when something breaks, you can see where and why. Your first loop can log step index, tool name, and latency before you add fancy evals.

So the short answer is trying to quantify anything and everything in that system that you're building.

Aishwarya Srinivasan, Fireworks AI, on Chain of Thought ep 42

Checklist

  • Can I write the happy path as a fixed DAG without a loop? If yes, start there.
  • If I need a loop, do I have a named stop condition (max steps, finish tool, or explicit terminal state)?
  • Are tool schemas small and bounded so the model cannot call arbitrary endpoints?
  • Does each iteration append observations to state so the model can recover from a bad tool call?
  • Before scaling users, do I log every step so I can trace failures (even if evals come later)?

The longer explainer, with the episode clips, is on Chain of Thought. It draws on this episode.

Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.

Drafted with AI assistance from the episode transcripts.

來源:DEV Community · dev.to