“AI将人类从人类性中开除”是艺术家ZHO抛出的命题也是一道工程难题。这句话听起来很哲学但落到开发领域它问的是同一个问题当大模型能够生成文案、代码、设计稿时人的位置在哪里我的回答是人的位置不在“更能写”而在“是否允许发布”。AI生成内容的速度越快、质量越高人在“生成到发布”之间的把关作用就越重要。下面用一个 Python FastAPI 大模型 API 实现的“可审核 Agent 服务”把这句话翻译成一套可运行的工程系统。这个服务可以让 Agent 先生成初稿再由人工审核决定是否发布审核结果会被完整记录下来。读完可以把它扩展到内容发布、企业内部助手、自动化工单处理等场景。在正式写代码前先解释一个判断AI 是否“开除”人类并不取决于模型本身的参数规模而取决于我们如何设计 AI 与外部系统之间的控制流。如果 AI 的输出直接对外发布那么人类确实只是旁观者如果在 AI 输出和最终结果之间加入审核、修改、驳回、审计节点人类就仍然掌握决策权。下面章节会先讲清这套控制流的概念再一步步实现它。1. 为什么说 AI 正在“接管创作”而工程上更该关注“谁来负责”1.1 一个艺术命题背后的工程问题艺术家 ZHO 的命题“AI 将人类从人类性中开除”是在提醒我们很多被看作“人类特质”的能力比如写作、绘画、编程正在被大模型以越来越低的价格复制。对于开发者来说这种焦虑并不新鲜。几年前代码生成工具刚出现时同样有人担心程序员失业。后来大家发现真正留存的岗位不是“写代码的人”而是“知道什么代码不该写、什么代码该合并、出问题谁负责”的人。工程上可以把这个问题拆成两层。第一层AI 能不能独立完成一项任务。这取决于模型能力、工具数量和上下文长度是技术问题。第二层AI 完成的任务能不能直接进入生产环境。这取决于责任边界、合规要求、团队协作方式是工程治理问题。很多个人开发者和中小企业把第一层做得很好却忽略第二层。结果是 AI 生成的内容直接发布发现问题后找不到责任人。这篇文章的重点不是继续提高 AI 的生成能力而是给 AI 输出加一道“人工闸门”。1.2 把“人”放回 AI 工作流从生成到发布之间加一道闸门常见的 AI 应用有三种形态。第一种是“直接对话”用户提问模型回答。这种形态适合聊天、翻译、写文案初稿但回答直接可见不可控。第二种是“后处理”模型生成内容代码做规则过滤或敏感词检查再输出。这种形态能在一定程度上拦截问题但规则无法覆盖模型的语义偏差。第三种是“人工审核”模型生成草稿进入待审核状态由人来批准、修改或驳回审核通过后才对外发布。这种形态最适合内容生产、工具调用、自动化决策等场景。要让“人工审核”真正有效不能只在展示层加一个“是否确认”按钮而是要把审核作为整个工作流的一个必要状态节点。也就是说任务状态必须包含“待审核”这一项并且没有人工的明确动作任务不能进入终态。1.3 全文目标与技术主线下面这套示例会实现一个最小但完整的“可审核 Agent 服务”用户提交一个自然语言任务。Agent 收到任务后可以调用内置工具获取信息并生成一个初稿。初稿不会直接返回给用户而是进入“待审核”状态。人工通过接口审核选择批准、修改后批准、驳回。整个过程的输入、输出、工具调用和审核结果都会记录在内存数据库中。通过跑通这个流程你会理解为什么 AI 应用不能只停留在“调用 API”层面为什么需要状态机为什么人工审核节点不是多余的以及生产环境还需要哪些额外保障。2. 可审核 Agent 的核心概念与总体设计2.1 Agent 不是“高级聊天框”而是“带工具的执行器”“Agent”这个词在 AI 工程里越来越常见但很多人只是把它当成一个更聪明的聊天框。实际上Agent 的核心特征是“带工具”。普通大模型 API 的交互模式是用户输入 - 模型输出文本Agent 的交互模式是用户输入 - 模型决定调用哪个工具 - 代码执行工具 - 返回结果给模型 - 模型继续生成其中“模型决定调用哪个工具”这一步通过 Function Calling 或 Tool Calling 完成。模型返回的不是一段最终文本而是一个结构化请求例如{ name: get_current_time, arguments: {} }我们的程序收到这个请求后负责执行真实的函数并把返回值交还给模型。这样模型就具备了访问外部系统、计算环境、数据库的能力。但“工具”是双刃剑。工具越多Agent 能做越多事同时风险也越大。一个只读天气接口和一个能执行任意 Shell 命令的接口造成的风险完全不同。所以在设计中工具必须是显式的白名单且每个工具都要有明确的输入输出格式。2.2 可审核工作流生成草稿、人工审批、最终发布可审核 Agent 的工作流可以抽象成四个阶段生成阶段用户输入任务Agent 尝试规划并调用工具最终生成一份草稿。暂存阶段草稿被标记为pending_review不对外发布。审核阶段人工查看草稿选择批准、修改或驳回。终态阶段批准后的内容成为最终结果或进入后续发布流程驳回的任务状态被关闭并记录反馈。这套工作流的状态机非常关键。任务不能直接从“生成草稿”跳到“已完成”必须经过“待审核”。状态含义允许流转到pending_review草稿生成完毕等待人工审核approved/rejectedapproved人工批准草稿或修改稿成为最终结果终态rejected人工驳回可以附带反馈终态或重新生成在实际项目中状态可以更多比如running、failed、timeout、published。但最小闭环只需要这三个状态。2.3 技术选型与项目结构示例采用以下技术栈Python 3.9 或更高版本FastAPI提供 HTTP 接口和请求校验Uvicorn运行 FastAPI 服务Pydantic定义数据模型OpenAI Python SDK调用 OpenAI 兼容接口python-dotenv加载环境变量选openaiSDK 而不是直接requests是因为它原生支持tools参数代码会更简洁。如果你使用的是通义千问、DeepSeek、Ollama 这类兼容 OpenAI 接口的服务只需要修改base_url和api_key。项目目录结构如下ai_review_agent/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── config.py │ ├── schemas.py │ ├── tools.py │ ├── llm_client.py │ ├── agent.py │ └── store.py ├── .env └── requirements.txt各文件职责可以先用一张表说明后面会逐个展开。文件职责config.py加载环境变量schemas.py定义请求、响应、状态枚举tools.py定义 Agent 可用的工具白名单llm_client.py封装大模型客户端agent.py控制 Agent 执行流程store.py内存存储任务状态main.pyFastAPI 路由与人工审核入口3. 环境准备与依赖配置3.1 环境要求先准备一个干净的 Python 环境。示例代码依赖较少但有两个前置条件一台可以运行 Python 的机器建议 Python 3.9。一个大模型服务。可以是云端兼容接口也可以是本地 Ollama。不同模型接入方式会影响.env配置但代码结构基本一致。3.2 创建虚拟环境并安装依赖建议在项目目录下创建虚拟环境mkdir ai_review_agent cd ai_review_agent python -m venv .venv source .venv/bin/activate在 Windows 下激活命令是.venv\Scripts\activate然后创建requirements.txtfastapi0.110.0 uvicorn0.29.0 openai1.30.0 pydantic2.7.0 python-dotenv1.0.1这些版本只是示例实际项目落地前要先确认与自身系统、Python 版本、模型服务商 SDK 的兼容性。安装命令pip install -r requirements.txt3.3 环境变量与两种模型接入方式在项目根目录创建.envLLM_API_KEYEMPTY LLM_BASE_URLhttp://localhost:11434/v1 LLM_MODELqwen2.5:7b APP_PORT8000 TIMEOUT_SECONDS120这里默认配置指向本地 Ollama 服务。如果你使用的是云端 API可以改成LLM_API_KEYsk-your-api-key LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini需要注意Ollama 的 OpenAI 兼容接口是/v1不要漏掉。接入方式对比方式优点缺点适用场景云端 API开箱即用模型能力强需要联网数据出外网业务原型、生产环境有合规方案时本地 Ollama数据不出内网离线可用硬件要求高模型能力受限数据敏感场景、开发调试如果使用本地 Ollama先把模型下载下来并启动服务ollama pull qwen2.5:7b ollama serve确认服务可访问curl http://localhost:11434/v1/models返回模型列表说明服务正常。4. 从数据模型到 Agent 流程的完整实现4.1 任务数据模型设计先定义任务的数据结构。任务状态是整个系统最核心的部分它不仅描述任务当前在哪一步还决定哪些接口允许操作。在app/schemas.py中写入from datetime import datetime from enum import Enum from typing import Optional from pydantic import BaseModel, Field class TaskStatus(str, Enum): pending_review pending_review approved approved rejected rejected class ReviewDecision(str, Enum): approve approve reject reject edit_and_approve edit_and_approve class TaskCreate(BaseModel): input_text: str Field(..., min_length1, max_length2000) class ReviewRequest(BaseModel): decision: ReviewDecision feedback: str Field(default, max_length1000) edited_content: Optional[str] None关键点TaskStatus控制任务生命周期。ReviewDecision控制人工审核的三个动作。edited_content在“修改后批准”场景下必填。字段长度限制可以避免恶意超长输入。接下来在app/store.py中实现一个简单的内存存储import uuid from datetime import datetime from typing import Dict, Optional tasks_db: Dict[str, dict] {} def create_task(input_text: str, draft_result: str) - dict: now datetime.utcnow().isoformat() task { task_id: uuid.uuid4().hex, input_text: input_text, draft_result: draft_result, final_result: None, status: pending_review, review_feedback: , created_at: now, updated_at: now, } tasks_db[task[task_id]] task return task def get_task(task_id: str) - Optional[dict]: return tasks_db.get(task_id) def update_task(task_id: str, **kwargs) - dict: task tasks_db[task_id] task.update(kwargs) task[updated_at] datetime.utcnow().isoformat() return task这里用dict演示足够跑通最小闭环。生产环境需要替换为 Redis、MySQL 或 PostgreSQL并加上事务和索引。4.2 工具集Agent 的能力边界为了让示例安全、可复现内置两个简单工具get_current_time获取当前系统时间。get_random_number获取指定范围内的随机整数。在app/tools.py中写入import random from datetime import datetime TOOLS [ { type: function, function: { name: get_current_time, description: 获取当前系统时间返回格式为 YYYY-MM-DD HH:MM:SS, parameters: { type: object, properties: {} } } }, { type: function, function: { name: get_random_number, description: 获取一个指定范围内的随机整数需要传入最小值和最大值, parameters: { type: object, properties: { min_value: {type: integer, description: 最小值}, max_value: {type: integer, description: 最大值} }, required: [min_value, max_value] } } } ] def call_tool(name: str, arguments: dict) - str: if name get_current_time: return datetime.now().strftime(%Y-%m-%d %H:%M:%S) if name get_random_number: min_value int(arguments.get(min_value, 1)) max_value int(arguments.get(max_value, 100)) if min_value max_value: min_value, max_value max_value, min_value return str(random.randint(min_value, max_value)) return f未知工具: {name}这里要理解两个概念。第一个是“工具描述”。TOOLS里的 JSON 结构是给模型看的模型会根据你的描述决定是否调用工具。描述写得越清楚模型越不容易乱用。比如get_random_number里写了参数含义和用途模型就能自动从用户的话里抽出最小值和最大值。第二个是“工具实现”。call_tool是真实代码执行的地方。这里有一个安全原则工具白名单越短越好不要给 Agent 暴露无限制的接口。如果模型能调用run_command、delete_file这类工具出问题后很难追责。4.3 大模型客户端接入 OpenAI 兼容 API在app/config.py中写入import os from dotenv import load_dotenv load_dotenv() class Config: llm_api_key os.getenv(LLM_API_KEY, EMPTY) llm_base_url os.getenv(LLM_BASE_URL, http://localhost:11434/v1) llm_model os.getenv(LLM_MODEL, qwen2.5:7b) app_port int(os.getenv(APP_PORT, 8000)) timeout int(os.getenv(TIMEOUT_SECONDS, 120)) config Config()在app/llm_client.py中写入from openai import OpenAI from app.config import config client OpenAI( api_keyconfig.llm_api_key, base_urlconfig.llm_base_url, timeoutconfig.timeout, ) def run_llm_with_tools(messages, toolsNone): response client.chat.completions.create( modelconfig.llm_model, messagesmessages, toolstools, temperature0.3, ) return response.choices[0].messagetemperature0.3是为了让模型在调用工具和生成草稿时更稳定减少随机性。如果做创意写作可以调高到 0.7 左右但在包含工具调用的 Agent 流程里先保持低温度更利于排查问题。4.4 Agent 执行流程规划、调用工具、生成草稿在app/agent.py中实现 Agent 的核心循环import json from app.llm_client import run_llm_with_tools from app.tools import TOOLS, call_tool from app.store import create_task SYSTEM_PROMPT 你是一个辅助生成初稿的AI。你需要根据用户的需求合理调用工具获取信息然后生成一段简洁、可读的内容。生成完初稿后不要告诉用户“我需要确认”直接把初稿内容返回。 def run_agent(input_text: str) - dict: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: input_text}, ] max_iterations 10 for _ in range(max_iterations): message run_llm_with_tools(messages, toolsTOOLS) if not message.tool_calls: draft message.content or 模型没有生成结果 return create_task(input_text, draft.strip()) for tool_call in message.tool_calls: function_name tool_call.function.name function_args json.loads(tool_call.function.arguments or {}) print(f[tool] {function_name}({function_args})) result call_tool(function_name, function_args) messages.append({ role: assistant, content: None, tool_calls: [tool_call], }) messages.append({ role: tool, tool_call_id: tool_call.id, content: result, }) return create_task(input_text, Agent执行次数超限未能生成初稿)这个循环做的事情是把系统提示词和用户输入发送给模型。如果模型返回的是普通文本就把它作为草稿创建任务。如果模型返回了tool_calls就解析工具名和参数执行真实工具然后把工具返回结果追加到消息列表再次请求模型。最多循环 10 次避免模型反复调用工具造成死循环。这里的关键是messages里如何拼接工具调用。OpenAI 兼容接口要求携带tool_calls的 assistant 消息后面必须跟一组roletool的消息并用tool_call_id对应到具体调用。拼接错误会导致接口报错。4.5 FastAPI 接口与人工审核入口在app/main.py中实现 HTTP 接口from fastapi import FastAPI, HTTPException from app.schemas import TaskCreate, ReviewRequest, ReviewDecision, TaskStatus from app.store import get_task, update_task from app.agent import run_agent app FastAPI(title可审核 AI Agent 服务) app.get(/health) def health(): return {status: ok} app.post(/api/tasks) def create_task_handler(body: TaskCreate): task run_agent(body.input_text) return task app.get(/api/tasks/{task_id}) def get_task_handler(task_id: str): task get_task(task_id) if not task: raise HTTPException(status_code404, detail任务不存在) return task app.post(/api/tasks/{task_id}/review) def review_task_handler(task_id: str, body: ReviewRequest): task get_task(task_id) if not task: raise HTTPException(status_code404, detail任务不存在) if task[status] ! TaskStatus.pending_review.value: raise HTTPException(status_code400, detail只有待审核状态的任务才能执行审核) if body.decision ReviewDecision.approve: update_task( task_id, statusTaskStatus.approved.value, final_resulttask[draft_result], ) elif body.decision ReviewDecision.reject: update_task( task_id, statusTaskStatus.rejected.value, final_resultNone, review_feedbackbody.feedback, ) elif body.decision ReviewDecision.edit_and_approve: if not body.edited_content: raise HTTPException(status_code400, detail选择修改并审核通过时edited_content 不能为空) update_task( task_id, statusTaskStatus.approved.value, final_resultbody.edited_content, review_feedbackbody.feedback, ) return get_task(task_id)这个接口设计体现了“人工审核”的三个动作approve直接采用 AI 草稿。reject驳回不发布可填写反馈。edit_and_approve人工修订后采用修订稿。这样做的业务意义是AI 的输出不是最终事实而是“建议稿”。真正拥有最终决定权的还是人。4.6 启动入口在app/main.py末尾添加启动逻辑if __name__ __main__: import uvicorn from app.config import config uvicorn.run(app, host0.0.0.0, portconfig.app_port)开发时也可以用命令行启动uvicorn app.main:app --reload --port 8000注意当前服务是同步执行 Agent 的。也就是说创建任务时 HTTP 请求会一直等待模型和工具执行完毕。这个复杂度不高但模型响应慢时请求会占用较长时间。生产环境应该把 Agent 执行放到任务队列中例如 Celery、Arq 或 Redis Stream并把任务状态同步到数据库。5. 运行验证从创建任务到人工审核通过5.1 启动服务并确认健康状态在项目根目录执行uvicorn app.main:app --reload --port 8000看到类似输出INFO: Uvicorn running on http://0.0.0.0:8000 INFO: Application startup complete.另开一个终端确认健康检查curl http://127.0.0.1:8000/health返回{status:ok}5.2 创建一个需要调用工具的 Agent 任务用下面的请求创建任务让 Agent 获取当前时间并尝试生成一段带时间的回复curl -X POST http://127.0.0.1:8000/api/tasks \ -H Content-Type: application/json \ -d {input_text: 现在是什么时间请用一句话告诉我当前时间。}如果模型正确执行了工具调用你应该会在 Uvicorn 控制台看到类似[tool] get_current_time({})接口返回一个处于待审核状态的任务{ task_id: a1b2c3d4e5f6, input_text: 现在是什么时间请用一句话告诉我当前时间。, draft_result: 当前时间是2026-05-12 14:30:22。, final_result: null, status: pending_review, review_feedback: , created_at: 2026-05-12T14:30:22.123456, updated_at: 2026-05-12T14:30:22.123456 }注意观察status不是approved也不是completed而是pending_review。这正是整个设计的关键AI 生成的草稿已经产生但它还不能算最终结果。请求中的input_text字段名要和TaskCreate中的字段名一致。如果你用的是示例数据结构字段是input_text不是input或prompt。5.3 查询任务状态并检查日志在人工没有审核之前可以用查询接口确认状态curl http://127.0.0.1:8000/api/tasks/a1b2c3d4e5f6返回结果和创建时基本一致。同时在 Uvicorn 控制台可以看到模型调用和工具执行的日志。这是排查 Agent 行为的重要手段。如果日志里没有出现[tool]但任务最终仍然生成了草稿说明模型直接给出了回答没有调用工具。这并不一定是错误但你可以检查工具描述是否清晰或者提示词是否要求模型必须使用工具。5.4 人工审核批准、修改、驳回三种结果先试“批准”curl -X POST http://127.0.0.1:8000/api/tasks/a1b2c3d4e5f6/review \ -H Content-Type: application/json \ -d {decision: approve}返回{ task_id: a1b2c3d4e5f6, status: approved, final_result: 当前时间是2026-05-12 14:30:22。 }再试“修改后批准”curl -X POST http://127.0.0.1:8000/api/tasks/a1b2c3d4e5f6/review \ -H Content-Type: application/json \ -d {decision: edit_and_approve, edited_content: 当前时间是2026-05-12 14:30已由人工确认。}返回后final_result会变成人工修改后的内容而不是 AI 的原始草稿。最后试“驳回”curl -X POST http://127.0.0.1:8000/api/tasks/a1b2c3d4e5f6/review \ -H Content-Type: application/json \ -d {decision: reject, feedback: 时间格式不满足要求请改成北京时间。}驳回后任务进入终态rejectedfinal_result为空反馈记录被保存。三种审核动作的预期结果汇总审核动作状态变化最终结果使用场景approvepending_review-approved使用 AI 草稿AI 生成质量足够好edit_and_approvepending_review-approved使用人工修改稿AI 方向正确但细节需要修正rejectpending_review-rejected无最终结果生成内容不符合要求需要重新生成6. 常见问题排查从模型报错到审核不生效6.1 模型连接失败或返回 401现象创建任务时接口返回 500或 Uvicorn 日志中出现401 AuthenticationError。可能原因LLM_API_KEY配置错误或LLM_BASE_URL路径不对。检查方式cat .env curl -v http://localhost:11434/v1/models如果使用云端 API先确认 API Key 是否有效。如果使用本地 Ollama确认服务已经启动并且LLM_BASE_URL是http://localhost:11434/v1。处理建议密钥不要硬编码在代码里统一放.env。每次修改.env后重启服务。检查服务商文档确认兼容接口的路径前缀。6.2 工具调用形同虚设或频繁死循环现象一模型从不调用工具只凭内部知识回答。原因可能是tools参数没传或者模型对工具理解不足。先在代码里确认run_llm_with_tools的调用带了toolsTOOLS。然后可以在提示词中强调“如果有必要请调用工具获取实时信息”。现象二模型反复调用同一个工具始终不生成最终文本。这通常是messages拼接错误或者工具返回内容无法让模型结束循环。解决办法是给 Agent 循环设置最大迭代次数示例中已经用max_iterations 10兜底。拿到“执行次数超限”的结果后去控制台看最后几轮消息确认工具返回是否过于模糊。6.3 本地 Ollama 跑得不快或不调用函数很多人在本地跑 Ollama但发现速度很慢甚至模型不调用函数。先确认 Ollama 是否使用了 GPUollama ps如果PROCESSOR列显示100% CPU说明模型没有加载到 GPU。可以尝试重启 Ollama并确认系统已安装 CUDA 驱动。nvidia-smi如果nvidia-smi不存在说明 GPU 环境没有配置好。Ollama 在 Linux 下会自动寻找 NVIDIA GPUWindows 下需要安装合适版本的 CUDA 驱动。函数调用方面Ollama 的 OpenAI 兼容接口对tools的支持取决于模型本身。部分模型不支持 Function Calling或者支持得不稳定。如果模型不调用工具可以降级方案用提示词让模型输出一个 JSON例如{tool: get_current_time, arguments: {}}然后代码解析 JSON 执行工具。这个方案兼容性更强但需要额外的错误处理。6.4 人工审核状态丢失或任务卡在 pending现象任务创建后重启服务再用原task_id查询返回 404。原因是当前store.py使用内存字典服务重启后数据全部丢失。处理建议开发阶段可以接受内存存储。生产环境必须换成 Redis 或 MySQL。如果任务一直卡在pending_review检查是否有另一个进程在修改数据库或者事务没有提交。对于审核超时可以增加“自动提醒”或“超时回收”任务避免审核节点长期占用。6.5 请求超时与并发处理现象模型响应很慢FastAPI 接口长时间不返回最终报TimeoutError。原因同步执行 Agent且OpenAI客户端的timeout设置得太短。处理建议调大TIMEOUT_SECONDS但不要盲目调大否则会拖垮服务。把 Agent 执行改造成异步任务接口只负责提交任务并返回task_id。生产环境限制单机并发使用信号量或消息队列控制请求量。7. 最佳实践与扩展方向7.1 上线前检查清单把示例跑通之后如果要继续用到真实业务建议按下面的清单检查一遍。密钥是否已经外置并且没有提交到 Git 仓库。.env是否加入了.gitignore。工具白名单是否已经收敛到最小集。是否禁止了eval、exec、任意 Shell 命令等危险操作。是否加入了日志记录包括模型请求参数、工具调用参数、审核人、审核时间。是否设置了模型调用超时和 Agent 循环上限。是否接入数据库避免进程重启后任务状态丢失。是否区分了draft_result、final_result、review_feedback避免审核信息混在一起。是否有人工审核的通知机制避免任务长时间无人处理。是否有回滚方案当发布内容出问题时能快速下线或恢复旧版本。7.2 从最小示例到生产环境的演进路径最小示例只有三个状态生产环境可以按这个顺序扩展第一阶段把内存存储替换为 Redis 或 MySQL。任务状态、草稿、审核结果都要持久化。第二阶段引入消息队列。创建任务后马上返回task_idAgent 在后台执行前端通过 WebSocket 或轮询获取任务状态。第三阶段增加一个简单的审核前端让操作者可以看到草稿、修改、通过或驳回而不是每次都用curl。第四阶段增加安全审核规则。比如先做敏感词过滤然后再进入人工审核减轻人工负担。第五阶段增加规则引擎把低风险请求设为自动通过高风险请求必须人工审核。此时“人工审核”不再是一刀切而是分险种管理。7.3 让审核结果变成模型改进的反馈信号人工审核是成本最高的节点也是最值得利用的数据来源。每次reject和edit_and_approve都隐含了人的判断标准。例如模型把当前时间写成了 UTC但人工改成北京时间模型生成内容过于冗长人工删减。这些差异就是偏好数据。可以定期收集这些数据把input_text、draft_result、edited_content形成对比样本。使用 few-shot 提示词把人工修正后的内容作为示例下次生成时让模型参考。数据量足够后可以用这些样本做微调。这样人工审核从“成本中心”变成了“数据生产中心”。AI 不是把人开除而是通过人的每次修正变得更可靠。7.4 更进一步的工程方向如果你对这个话题感兴趣可以继续研究以下方向多 Agent 协作一个 Agent 负责生成一个 Agent 负责反驳和检查最后再进入人工审核。引入 RAG把企业内部文档作为工具或知识库让 Agent 基于真实资料生成草稿。审核路由用小型模型做初筛判断哪些任务可以自动通过哪些必须进入人工审核。可观测性为每个任务生成 trace_id记录从用户输入到工具调用到人工审核的完整链路。安全加固在工具调用层加入权限校验、操作审计、数据脱敏避免 Agent 越权访问敏感资源。回到开头那个命题AI 是否把人类从“人类性”中开除不取决于模型而取决于工程系统如何分配人与 AI 的职责。给 AI 输出加一道人工审核节点不只是一个功能而是一种明确的价值选择生成可以自动化但责任不能自动化。把上面的示例跑通后你已经拥有一个最小的责任边界系统。下一步要做的就是把你的业务规则、工具集合、审核流程一点一点加进去。