AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
Build AI Employees in Python That Work While You Sleep - Analytics Vidhya India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder d : h : m : s Career GenAI Prompt Engg ChatGPT LLM Langchain RAG AI Agents Machine Learning Deep Learning GenAI Tools LLMOps Python NLP SQL AIML Projects Reading list How to Become a Data Analyst in 2025: A Complete RoadMap A Comprehensive Learning Path to Tableau in 2025 A Comprehensive NLP Learning Path 2025 Learning Path to Become a Data Scientist in 2025 Step-by-Step Roadmap to Become a Data Engineer in 2025 A Comprehensive MLOps Learning Path: 2025 Edition Roadmap to Become an AI Engineer in 2025 A Comprehensive Learning Path to Master Computer Vision in 2025 Best Roadmap to Learn Generative AI in 2025 GenAI Roadmap for Enterprises Large Language Models Demystified: A Beginner’s Roadmap Learning Path to Become a Prompt Engineering Specialist Build AI Employees in Python That Work While You Sleep Riya Bansal. Last Updated : 22 Oct, 2026 10 min read It’s Friday, 8 a.m. Your weekly tech newsletter is drafted, fact-checked and waiting for one click of approval. You didn’t write it. You were asleep. Three AI employees did. A researcher found the week’s best links. A writer turned them into a draft. An editor caught the writer inventing a statistic, fixed it, and then left you a ticket asking for sign-off before anything went public. That’s exactly the behavior you want from a new hire. Now compare that to how most of us work with AI today. Thursday night, twelve tabs open. You paste a link into a chatbot, ask for a summary, paste it back, ask for a rewrite, then check whether the facts hold up. The AI is smart, but you’re still the one doing the managing. That’s not delegation. That’s babysitting. The difference between an assistant and an employee isn’t intelligence. It’s structure. An employee has one clear job, a defined set of tools, rules they can’t break and a manager who approves the risky calls. Give an AI agent the same structure and it can work unsupervised. In this tutorial, you’ll build AI employees in Python: a three-person newsletter crew that runs overnight. No frameworks, about 150 lines of code. Each employee gets a job contract, a toolbelt limited by agent tool permissions, and an AI approval workflow that keeps you in charge of anything that goes public. Table of contents Project Overview Project Architecture: How Your AI Employees Work Together Why Not Just Use Framework? Getting Started with the Project Step 1: The Rulebook Is Code, not a Pep Talk Step 2: Furnish the Office Step 3: Print the Tool Menu Step 4: Sign the Employment Contracts Step 5: Clocking In (The Agent Loop) Step 6: No File, No Paycheck Step 7: Run the Pass (Your Approval Desk) Your Turn: Three Upgrades to Try Conclusion Project Overview At the conclusion of this tutorial, you will successfully piece together an active crew that consists of the following: Three agents (Scout, Quill and Red) capitalizing on the same LLM engine Guardrails that are implemented in programming so agents will never be able to publish secrets or break the law Transfer technology whereby each agent is able to pass outputs Aside from that, you will also make the following installations: Approval desk so that when agents want to initiate high-risk operations, they will need approval from a human Cron scheduling so that your crew does its work even while you are sleeping Here’s a sample message that Red leaves you on a Friday morning: The editing agent apprehended the writing agent fabricating information. It then went ahead to rectify the document. Thereafter, it consulted you before proceeding to publicize the document. The conduct exhibited is what we need. This is meant for developers with a basic knowledge of Python and who have perhaps used an LLM API once or twice. You may use an OpenAI API key or even rely on free local models to follow. Project Architecture: How Your AI Employees Work Together Before writing any code, let’s look at how this team is organized. Think of it as a small company with three employees and one manager. The engine is shared. Every employee runs on the same LLM with the same configuration. You pick one model, and the whole team uses it. Switching models later changes the whole team at once. Each employee has one job. Scout researches, Quill writes and Red edits. Each one gets a written job contract, a fixed set of tools and a folder they’re allowed to write in. Nothing more. You are the manager. No employee can publish, send or delete anything. When Red thinks the newsletter is ready, it doesn’t hit publish. It files an approval ticket and waits for you. Work moves through files, not conversations. The employees never talk to each other. Each one finishes its task, leaves a file in a shared folder and clocks out. The next employee picks up that file and starts their shift: Here’s what each employee is allowed to do. The “Can’t” column isn’t a polite request. In Step 1, you’ll enforce it in code: Why Not Just Use Framework? Frameworks are useful once you know what you need. Until then, they hide the parts you should understand first. When does the loop stop? Who checks permissions? What happens when a website goes down? Write these 150 lines yourself, and the answers become obvious. When you do move to a framework, you’ll pick the one you actually need, not the one with the most popular launch video. Getting Started with the Project For this task, Python 3.10 or a later version is required along with a model capable of tool calling. You can use any OpenAI-compatible endpoint including a local model that you can use for free. kdir night-shift && cd night-shift python3 -m venv .venv && source .venv/bin/activate pip install "openai>=1.40" mkdir roles memory inbox Now you create .env. Choose one engine that you can use throughout your operations. # Option A: OpenAI OPENAI_API_KEY=sk-... MODEL=gpt-4.1-mini # Option B: free and local with Ollama (run: ollama pull qwen2.5:7b) # OPENAI_BASE_URL=http://localhost:11434/v1 # OPENAI_API_KEY=ollama # MODEL=qwen2.5:7b MAX_STEPS=15 The OpenAI SDK picks up OPENAI_API_KEY and OPENAI_BASE_URL automatically, and shift.py reads MODEL and MAX_STEPS. To switch engines later, you only edit .env. Step 1: The Rulebook Is Code, not a Pep Talk Some tutorials give instructions in their prompts, “Don’t ever publish.” That’s just a pep talk. Models are obedient most of the time. “Most of the time” is not very good at 3 a.m. Here’s the version you’ll find everywhere: # Before: the "rule" is a polite sentence the model may ignore SYSTEM = "You are a writer. Please do not publish or send emails." tools = [read_file, write_file, publish_post, send_email] # all of them! And here is ours, called roster.py: # After: tools and write paths are enforced by code, not by vibes ROSTER = { "scout": { "tools": ["read_file", "fetch_url", "write_file"], "writes": ["handoffs/"], "done": "handoffs/{today}/links.md", }, "quill": { "tools": ["read_file", "write_file"], "writes": ["drafts/"], "done": "drafts/{today}/issue.md", }, "red": { "tools": ["read_file", "write_file", "request_approval"], "writes": ["out/"], "done": "out/{today}/review.md", }, } Take a close look. There’s no publishing functionality anywhere in the room. Thus, Red can only ask, since you cannot misuse the tools, you were never granted to begin with. Step 2: Furnish the Office Several tools are required for every office. One should not overdo with the tools of the office. Save it as tools.py: import json, re, time, pathlib, urllib.request ROOT = pathlib.Path(file).parent.resolve() def _safe(path): p = (ROOT / path).resolve() if ROOT not in p.parents: raise PermissionError(f"{path} is outside the office") if p.name.startswith(".env"): raise PermissionError("secrets are off limits") return p def read_file(path): return _safe(path).read_text()[:8000] def write_file(path, content, allowed): p = _safe(path) rel = p.relative_to(ROOT).as_posix() # kills "handoffs/../out" tricks if not any(rel.startswith(prefix) for prefix in allowed): return f"DENIED: you may only write under {allowed}" p.parent.mkdir(parents=True, exist_ok=True) p.write_text(content) return f"wrote {len(content)} chars to {path}" The _safe() function can be referred to as the office door. Agents cannot get outside the project directory. Also, they cannot read .env. An agent which will come across the API key will inevitably leak it. Don’t forget to add the final two tools into this file: def fetch_url(url): req = urllib.request.Request(url, headers={"User-Agent": "night-shift/0.1"}) html = urllib.request.urlopen(req, timeout=15).read().decode("utf-8", "ignore") html = re.sub(r"", "", html, flags=re.S) text = re.sub(r"]+>", " ", html) return re.sub(r"\s+", " ", text)[:4000] def request_approval(action, summary, artifact): # The fence: risky verbs become a ticket, never an action. ticket = {"action": action, "summary": summary, "artifact": artifact, "asked_at": time.ctime()} pending = ROOT / "pending" pending.mkdir(exist_ok=True) path = pending / f"{int(time.time())}-{action}.json" path.write_text(json.dumps(ticket, indent=2)) return f"queued for human approval: {path.name}" The function request_approval is the most important one in the article. The function is not supposed to publish anything. It creates a ticket and waits for a human being. Step 3: Print the Tool Menu The model is unable to process your Python code. All it can read is the menu made in JSON format. Save it as schemas.py file: def _fn(name, desc, **props): return {"type": "function", "function": { "name": name, "description": desc, "parameters": {"type": "object", "required": list(props), "properties": {k: {"type": "string", "description": v} for k, v in props.items()}}}} SCHEMAS = { "read_file": _fn("read_file", "Read a file in the workspace.", path="Relative path"), "write_file": _fn("write_file", "Create or overwrite a file.", path="Relative path", content="Full file text"), "fetch_url": _fn("fetch_url", "Fetch a web page as plain text.", url="Full https URL"), "request_approval": _fn("request_approval", "Ask the human to approve a risky action like publish or send.", action="publish | send | spend | delete", summary="One line on what and why", artifact="Path to the file"), } Each agent can only find the tools that it has in its own toolbox. Quill’s toolbox has two menu items only. Step 4: Sign the Employment Contracts A charter refers to a job contract. It is created once and does not require updates. Its purpose is to answer five questions: output, inputs, limits, outcomes, and checkpoints. A charter from Scout is as follows: # Scout: research desk Outcome: a shortlist of this week's best links for the newsletter. Sources: only the URLs in inbox/sources.txt. Read that file first. Constraints: fetch each URL once. Skip pages that fail. Max 5 picks. Deliverable: write handoffs/{today}/links.md. For each pick add: title, URL, a two-line summary, and why our readers should care. If a source failed, list it under "## Gaps". Never invent a link. Stop as soon as the file is written. Quill and Red will fill in the same template. Quill writes 400 words based on the contents of the Scout list. Red checks each hyperlink, fixes any issues, and obtains the necessary approvals. I specifically prefer the boring part of the charter because Quill’s contract mentioned what to do in case Scout’s list is blank. Hence, when encountering an empty Scout file, Quill would write an enjoyable newsletter about nothing! - Newsletter name: The Friday Byte. Audience: working data folks. - Voice: short sentences, no hype words, one joke max per issue. - Never use the words "revolutionary" or "game-changing". - Sign-off is al [truncated for AI cost control]