跪拜 Guibai
← All articles
Frontend · Agent

From Job Description to Colleague: Building Your First AI Agent in 100 Lines

By 莪_幻尘 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Agents turn AI from a prompt-driven chatbot into an autonomous worker that can run multi-step jobs unattended, audit its own decisions, and collaborate with other specialized Agents. The difference in output quality between a single overloaded Agent and a team of narrowly-scoped Agents is the difference between "barely usable" and "needs no edits."

Summary

The core distinction between a Skill and an Agent is autonomy. A Skill is a passive Markdown document that executes a fixed process only when triggered. An Agent runs a ReAct loop—observe, think, act, evaluate—deciding its own next steps, retaining short- and long-term memory, and handing off tasks to other specialized Agents. The OpenAI Agents SDK makes this practical in roughly 100 lines of Python.

Two working examples are built from scratch. First, a single Research Agent that breaks a question into sub-questions, searches the web via Tavily, evaluates whether information is sufficient, and writes a structured report to disk—with hard limits on search rounds to prevent infinite loops. Second, a three-Agent dev team: a PM Agent produces a technical spec, a Coder Agent implements it, and a Reviewer Agent checks the code against acceptance criteria. If the review fails, the Reviewer hands back to the Coder automatically, with a retry cap enforced by an outer loop.

Five hard-won pitfalls are detailed: mistaking a long prompt for an Agent, overloading a single Agent with too many tools (accuracy drops from ~90% to ~50%), building an omnipotent Agent that does everything poorly, forgetting to set `max_turns` (one Agent burned $3.20 in tokens running 47 searches unattended), and skipping human-in-the-loop for destructive operations like `rm -rf`. Model switching—to local Ollama for privacy, to Claude via LiteLLM, or to enterprise vLLM—is covered with concrete code changes.

Takeaways
A Skill is a passive Markdown instruction sheet; an Agent is a runnable program with a ReAct loop (observe → think → act → evaluate) that decides its own next steps.
Each Agent should carry at most 5–7 tools. Accuracy drops from ~90% with 3–5 tools to ~50% with 30+ tools.
Splitting one omnipotent Agent into three narrow Agents (Researcher, Coder, Reviewer) lifted output quality from "barely usable" to "basically no changes needed."
Always set `max_turns`; without it, an Agent can loop indefinitely—one unattended run burned $3.20 in tokens across 47 searches.
Destructive operations must use `needs_approval=True` to pause for human confirmation before executing deletes, money moves, or permission changes.
Tool return values must be truncated (e.g., `[:2000]`) because they dominate token consumption—50% of total cost in a typical Research Agent run.
Handoff chains (PM → Coder → Reviewer) with an outer retry loop create a self-correcting dev team; failed reviews automatically send work back to the Coder.
Switching from cloud APIs to local Ollama requires changing only the client connection—two lines of code—while Agent logic and tool definitions stay identical.
The OpenAI Agents SDK runs in 5 lines of code, supports 100+ models, and provides built-in Tracing for auditing every decision step.
Custom GPTs lack autonomous loops, persistent memory, multi-Agent collaboration, and code-level control; they are a trial experience, not a real Agent.
Conclusions

The ReAct loop is the irreducible core of agency—without it, even a 3,000-character System Prompt is just a chatbot with a long instruction manual.

Tool count is a sharp accuracy lever: the jump from 5 to 30 tools cuts reliability roughly in half, making narrow-scope Agents a practical necessity rather than an architectural preference.

Token economics invert intuition—tool return values, not model reasoning, consume half the budget, so return-value truncation is the single highest-leverage cost control.

The PM-Coder-Reviewer Handoff pattern with automatic rejection-and-retry mirrors a real team's quality loop, and the quality jump from self-review to independent review is immediate and measurable.

The individual-vs-enterprise split is not about capability but about infrastructure overhead; a single `.py` file and `.env` suffice for personal use, while enterprise demands K8s, Vault, and audit logging.

Local 7B models can run Agents but at ~60% success rate versus 95%+ for GPT-4o on the same task, making them viable only for simple, high-frequency, or privacy-sensitive workloads.

Concepts & terms
ReAct (Reasoning + Acting)
The core Agent loop: observe the environment, think about what was observed, decide an action, execute it, then evaluate whether the goal is met. If not, loop again. This is what distinguishes an Agent from a single-shot LLM call.
Handoff
A mechanism in the OpenAI Agents SDK that transfers execution from one Agent to another. Used to build multi-Agent pipelines where, for example, a PM Agent hands a spec to a Coder Agent, which then hands code to a Reviewer Agent.
Human-in-the-loop
A safety pattern where an Agent pauses before executing a dangerous operation and waits for explicit human approval. In the SDK, this is implemented via `needs_approval=True` on tool decorators.
Guardrails
Input/output validation checks built into the OpenAI Agents SDK that can intercept dangerous instructions (e.g., 'rm -rf', 'drop table') before they reach the Agent's execution loop.
max_turns
A hard limit on the number of tool-calling rounds an Agent is allowed. Without it, an Agent can loop indefinitely because it has no intrinsic concept of 'enough information.'
Source: juejin.cn ↗ Google Translate ↗ Backup ↗