你建了 AI 智能體，但一個函數可能已經足夠

A user asks your app to summarize a document.

Your system creates a plan.

A planner agent assigns the task to a research agent.

A writer agent drafts the summary.

A reviewer agent checks the draft.

Then another agent decides whether the reviewer is satisfied.

Meanwhile, the user is still waiting for five bullet points.

Before adding another agent, ask: what decision actually needs one?

This is an architectural question worth answering before you build.

1. Separate the uncertain work from the predictable work

Consider an invoice-processing feature.

Some parts require interpreting messy information:

• Finding the supplier name in an unfamiliar layout.
• Understanding a description.
• Extracting fields from inconsistent documents.

Other parts have explicit rules:

• Is the invoice number present?
• Does the arithmetic add up?
• Is the supplier already registered?
• Has this invoice already been processed?
• Does this user have permission to approve it?

A useful design might be:

1. Extract text.
2. Ask a model to identify relevant fields.
3. Validate the result in code.
4. Check permissions and duplicates.
5. Present the invoice for approval.

The model handles interpretation. Your application enforces the rules.

2. Understand what autonomy adds

A workflow follows a path you define.

An agent can choose its next step based on what it observes.

Anthropic makes this distinction in its guidance on building effective agents and recommends starting with simpler approaches before increasing complexity.

That flexibility is useful when the required steps are difficult to predict.

For example, investigating a repository bug may involve searching files, reproducing behavior, examining dependencies, and changing direction after a failed hypothesis.

By comparison, turning a validated form submission into a database record usually has a known process.

Use autonomy where choosing the next step is part of the problem.

3. Write down the workflow before choosing the architecture

Take a support-email feature.

You might need to:

1. Read the message.
2. Classify the issue.
3. Retrieve the relevant account information.
4. Find an applicable policy.
5. Draft a response.
6. Ask a human to approve sensitive cases.

Now inspect each step.

Which ones require language understanding? Which ones are database queries? Which ones follow business rules?

You may discover that a small number of model calls inside a controlled workflow is enough.

That still gives the product useful AI capabilities.

4. Don’t ask the model to decide rules you already know

Suppose refunds are allowed only when several explicit conditions are met.

You could ask:

“Read this order and decide whether a refund is permitted.”

But if eligibility is fully defined, implement those checks in code.

The model can explain the result or identify information that needs review.

Your backend should enforce the actual permission and eligibility rules.

This makes the decision easier to test and audit.

It also gives you a clear place to update the policy.

5. Give every agent a reason to exist

Before introducing another agent, answer:

• What responsibility does it own?
• What information does it need?
• What does it produce?
• How will you verify that output?
• What happens when it disagrees with another agent?
• What evidence suggests it improves the result?

“Reviewer agent” sounds reassuring. But a reviewer needs clear criteria and access to relevant evidence.

A second model agreeing with the first is not independent proof that the answer is correct.

For calculations, use a calculation. For database state, query the database. For code behavior, run meaningful checks.

6. Measure the simpler version first

Build a baseline.

Depending on the task, that could be:

• A regular function.
• One model call.
• A fixed sequence of model calls.
• One agent with a small set of tools.

Run it on representative examples.

Record:

Then test a more complex approach against the same examples.

Keep the additional complexity when it produces a worthwhile improvement.

7. Use multiple agents when the work supports it

Multiple agents can be useful when subtasks are sufficiently independent.

For example, separate research tasks may be explored concurrently and combined afterward.

But if every step depends heavily on the previous step, splitting the work can introduce extra handoffs.

Each handoff needs a clear contract:

Input:
The question and relevant evidence.

Output:
Findings with source references and uncertainties.

Completion:
Required checks satisfied or a clear blocked status.

Anthropic’s guidance notes that teams can invest heavily in multi-agent designs only to find that improvements to a single agent achieve similar results. That makes a baseline comparison especially valuable.

8. Design for the user’s experience

The user sees a result, a wait, and a price.

They also experience the failures.

If your architecture makes a small request slow, expensive, or difficult to recover, the number of agents won’t compensate for it.

Ask:

• Can the user understand what is happening?
• Can they cancel?
• Is partial progress useful?
• Can a failed step resume safely?
• Does the result justify the wait?

These questions help connect architectural decisions to the product people actually use.

A quick decision guide

Before building an agent, ask:

Are the rules explicit?

Start with ordinary code.

Does one step require interpreting language or messy content?

Try a model call inside a defined workflow.

Does the system need to choose and revise its next steps?

Consider an agent.

Are there independent subtasks with a measurable benefit from parallel work?

Evaluate multiple agents.

These are starting points. Test them against your requirements.

Before you add another agent

Write one sentence:

“This agent improves the system because…”

Finish it with a specific responsibility and a way to measure the benefit.

If you can’t, keep investigating the simpler design.

A small function, a model call, and a well-defined workflow can be enough to build a useful product.

What’s one task you’ve seen turned into an agent that could have been handled more simply?