Overview
This forum post is a detailed Chinese-language walkthrough of Anthropic's guide "Building Effective Agents" (by Erik Schluntz and Barry Zhang, published December 19, 2024). After working with dozens of teams across industries, Anthropic found a counterintuitive truth: the most successful implementations use simple, composable patterns—not complex frameworks or specialized libraries.
Core Distinction: Workflow vs Agent
Anthropic classifies all LLM-enhanced systems as *agentic systems*, with a key architectural split:
| Type | Definition | Control | |------|------------|---------| | Workflow | LLMs and tools orchestrated through predefined code paths | Developer-controlled flow | | Agent | LLM dynamically decides its own process and tool usage | Model-autonomous control |
Core principle: don't build agents/workflows unless necessary. Agentic systems trade latency and cost for task performance. Find the simplest solution first; optimizing a single LLM call (RAG, in-context examples) is often enough.
When to Use Workflows: Five Patterns
1. Prompt Chaining — Decompose a task into sequential subtasks with checkpoints. Example: generate marketing copy, then translate it; write an outline, check it, then write the document. Trade latency for accuracy.
2. Routing — Classify input and dispatch to specialized follow-up tasks. Examples: customer support triage (general questions / refunds / tech support); routing easy queries to Haiku and hard ones to Sonnet.
3. Parallelization — *Sectioning* (MapReduce-style independent subtasks, e.g., one model handles queries while another filters inappropriate content) and *Voting* (run the same task multiple times, e.g., several prompts reviewing code for vulnerabilities).
4. Orchestrator-Workers — A central LLM dynamically decomposes tasks and delegates to worker LLMs. Unlike parallelization, subtasks are not predefined. Examples: editing an uncertain number of files; multi-source research.
5. Evaluator-Optimizer — One LLM generates, another evaluates and gives feedback in a loop. Works when feedback clearly improves responses (e.g., literary translation nuance, deciding whether further search is needed).
When to Use Agents
Agents fit open-ended problems where steps can't be predicted or hardcoded. Requirements: some trust in model decisions, a trusted execution environment, sandbox testing, and safeguards—since costs and error-accumulation risks are higher.
> An agent is just "an LLM in a loop, using tools based on environmental feedback to accomplish its task."
Examples: a coding agent solving SWE-bench tasks; the "computer use" reference implementation.
Three Design Principles
1. Keep it simple — avoid over-engineering. 2. Keep it transparent — explicitly show the agent's planning and steps. 3. Design the ACI (Agent-Computer Interface) carefully — this emerged as crucial. Best practices:
- Give the model room to "think" so it doesn't paint itself into a corner
- Use formats close to text models naturally see on the internet
- Avoid format overhead (no counting thousands of lines, no string escaping)
- Write parameter names/descriptions like good docstrings
- Test extensively how the model uses tools and iterate
- Apply poka-yoke: make errors structurally harder
- AI customer support: natural conversational flow, tool integration for customer/order data, programmable actions (refunds, ticket updates), measurable success. Some companies use pay-on-success pricing, signaling confidence in outcomes.
- Coding agents: verifiable via automated tests, well-defined problem space, objective quality metrics. Anthropic's agent solves real GitHub issues (SWE-bench Verified), though human review remains essential.
- Original: Building Effective Agents
- Authors: Erik Schluntz, Barry Zhang (Anthropic), December 19, 2024
Notably, while building their SWE-bench agent, Anthropic spent more time optimizing tools than the overall prompt. One fix: requiring absolute paths (models erred with relative paths after the agent left the root directory)—after which the model performed flawlessly.
On Frameworks
Frameworks mentioned: Claude Agent SDK, Strands Agents SDK (AWS), Rivet, Vellum. Recommendations:
1. Prefer direct LLM API calls—many patterns need only a few lines of code 2. If using a framework, understand the underlying code (false assumptions cause bugs) 3. Don't hesitate to strip abstraction layers in production
Extra abstraction can hide prompts/responses, complicate debugging, and tempt you into unnecessary complexity.
Summary of First Principles
| Principle | Meaning | |-----------|---------| | Start simple | Don't build giant control flows; provide robust atomic tools | | Build for deletion | Modular architecture; newer models will replace your logic | | Performance drives complexity | Add complexity only when performance clearly improves | | Tools are the interface | ACI matters as much as HCI |
Success = the right system, not the most complex system. Start with simple prompts, optimize with thorough evaluations, and only introduce multi-step agentic systems when simple solutions genuinely fall short.