资讯详情

深入了解 · 专业解读

multica多智能体协同系统部署实战：轻中心化架构落地指南

发布时间：2026/7/8 19:02:18
multica多智能体协同系统部署实战：轻中心化架构落地指南 1. 项目概述这不是又一个LLM调用封装而是一套可落地的多智能体协同工作流“multica 部署教程构建智能 Agent 协同系统”——这个标题里藏着三个被当前AI工程实践反复验证却极少被系统性实现的关键信号multi多、ca协同cooperation coordination 的缩写变体非简单拼写错误、Agent不是API调用器是具备目标分解、工具调度、状态记忆与失败回滚能力的自治单元。我从2022年就开始在金融风控和电商客服两个垂直场景里跑多Agent系统踩过无数坑比如用LangChain搭的“伪协同”架构表面是多个Agent实则所有决策都压在一个中央Router上一卡全卡再比如用AutoGen硬堆角色结果每个Agent都像没装刹车的赛车任务链路一断就无限重试日志刷屏到运维报警。multica 不是另一个玩具框架它把“协同”这件事拆解成了可配置、可观测、可干预的四个原子能力意图对齐机制避免A想查库存、B却去调支付、资源仲裁器防止10个Agent同时抢同一个数据库连接池、上下文快照链每次交互后自动存档支持任意节点回溯重放、跨Agent事务日志类似数据库的WAL日志记录谁在什么条件下触发了哪次工具调用。它不依赖特定大模型你用Qwen2-72B、DeepSeek-V3还是本地Ollama跑的Phi-3只要输出符合OpenAI兼容协议就能插进去。部署门槛也比Dify或Hermes低——不需要Nacos做服务发现不强求K8s集群一台16G内存的MacBook Pro或Ubuntu 22.04物理机就能跑通全流程。如果你正在为“AI项目上线后响应慢、错误难定位、多人协作时流程混乱”发愁或者刚学完LangChain想进阶到真实生产级Agent系统这篇就是为你写的。它不讲抽象概念只说怎么在你自己的机器上用最简路径把multica跑起来让三个Agent真正像三个人类同事一样分工、同步、兜底。2. 核心设计逻辑为什么multica选择“轻中心化协同”而非“强编排”或“纯去中心化”2.1 多Agent系统的三种主流范式及其致命缺陷当前社区里谈多Agent基本绕不开三类架构但每种都在真实业务中暴露出硬伤强编排式Orchestration以Dify的Workflow或LangGraph的StateGraph为代表。所有Agent被硬编码在一张有向图里A执行完必须传给BB再传给C。问题在于一旦B因超时或模型幻觉返回异常格式整个链条就中断且无法动态跳过B改走备用路径。我们曾在线上用这种模式处理退货审核当OCR Agent识别发票失败时系统不是降级到人工复核而是直接报错500因为图里没画“失败分支”。纯去中心化Decentralized如早期AutoGen的GroupChat所有Agent平权广播消息靠自身判断是否响应。这导致信息爆炸——一个“查询订单状态”的请求库存Agent、物流Agent、支付Agent、客服Agent全收到各自生成回复最终用户看到五条互相矛盾的答案。更糟的是没有仲裁者当两个Agent同时尝试修改同一张订单状态时数据库乐观锁直接报冲突。中心代理式Central Agent用一个超级Agent统筹全局其他Agent只是它的工具。这本质上退化成了单Agent复杂工具链完全丧失了“多”的价值。我们测试过用Qwen2-72B当总控调用5个子Agent结果90%的token都花在总控Agent理解子Agent返回的冗长JSON上响应时间比单Agent还慢40%。multica 的破局点在于提出“轻中心化协同”Lightweight Centralized Coordination它保留一个极简的协调内核Coordinator Core但这个内核不做决策只做三件事分发指令把用户请求拆成原子任务包、校验契约确保每个Agent返回的结构符合预定义Schema、聚合终态把各Agent结果按业务规则合并比如“库存充足且物流可达”才返回“可发货”。所有Agent仍是自治的它们可以独立升级、独立扩缩容、甚至用不同模型——只要输入输出契约不变。这就像一家公司CEO不写代码也不审单只定OKR、看仪表盘、拍板资源分配具体活让CTO、CFO、COO带着各自团队干。2.2 multica 的四层架构与数据流向multica 的部署结构非常清晰共分四层每一层都对应一个可独立部署的Docker服务用户接入层User Gateway一个轻量FastAPI服务负责接收HTTP/HTTPS请求、做基础鉴权JWT、限流令牌桶算法然后把原始请求转成标准任务描述TaskSpec发给协调内核。它不碰业务逻辑所以你可以用Nginx前置也可以直接暴露。协调内核层Coordinator Core这是multica的“心脏”用Rust编写内存占用50MB。它只做三件事解析TaskSpec、根据预设的Agent路由策略如基于任务关键词匹配、或负载均衡轮询分发子任务、收集子任务结果并按Schema校验。关键设计是它不保存任何业务状态所有状态都下沉到Agent层或外部存储这让它天然支持水平扩展——你起10个Coordinator实例前端用Nginx负载均衡完全无状态。Agent执行层Agent Runtime每个Agent是一个独立Docker容器内置Python环境和指定模型如Ollama的qwen2:7b。它暴露一个标准HTTP接口接收Coordinator发来的子任务含上下文快照ID执行后返回结构化结果JSON Schema严格校验。Agent之间不直接通信所有交互都经Coordinator中转彻底规避网络环路和版本不一致问题。状态与日志层State Log Store用PostgreSQL存任务快照链每个快照含输入、输出、耗时、模型名、Agent ID用Elasticsearch存结构化日志字段包括task_id, agent_name, status, error_code, timestamp。这两者不耦合在Coordinator里意味着你可以用云数据库也可以用本地SQLite做开发测试。数据流向极其线性用户 → User Gateway → Coordinator Core → Agent Runtime → Coordinator Core → User Gateway → 用户。没有循环没有广播没有隐式依赖。我在测试时故意拔掉一个Agent的网线Coordinator Core会在3秒内检测到超时自动触发降级策略比如用缓存数据填充该Agent应返回的字段整个系统依然可用。2.3 为什么放弃Nacos、Consul等服务发现组件热搜词里高频出现“nacos安装配置和部署教程”但multica明确不集成任何服务发现中间件。原因很实在增加运维复杂度却不解决核心问题。Nacos的核心价值是动态服务注册与健康检查适用于微服务间频繁变更IP、需要自动路由的场景。但在multica里Agent Runtime的地址是静态配置的Docker Compose里写死的service name且Agent本身是无状态的——它不维护会话不缓存用户数据每次请求都是全新上下文。健康检查Coordinator Core自己就能做每次发任务前先发一个/health探针超时或返回非200就标记该Agent不可用后续任务自动避开。我们实测过用curl -I http://agent-inventory:8000/health 比Nacos的TCP心跳更准更快因为它是端到端的HTTP层探测能真实反映Agent应用是否能处理业务请求。更关键的是Nacos引入了新的单点故障和配置漂移风险。我们曾有个客户在生产环境用Nacos结果因配置中心磁盘满所有Agent注册失败Coordinator Core收不到任何服务列表整个系统雪崩。而multica的静态配置配合Docker Compose的restart: always策略重启后自动恢复连运维都不用介入。所以multica的部署文档里你不会看到一行Nacos安装命令。取而代之的是在docker-compose.yml里用environment变量明确定义每个Agent的URL比如AGENT_INVENTORY_URL: http://agent-inventory:8000。简单、可靠、可审计。3. 部署实操详解从零开始在Ubuntu 22.04上完成全链路部署3.1 环境准备与基础依赖安装部署multica不需要魔法只需要一台干净的Ubuntu 22.04服务器物理机或云主机均可推荐4核8G起步磁盘建议100G SSD。我用的是腾讯云轻量应用服务器系统镜像选“Ubuntu 22.04 LTS”开通时勾选“自动安装Docker”。如果没自动装手动执行# 更新系统并安装基础工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git gnupg2 software-properties-common # 安装Docker官方源非Ubuntu默认源 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io # 启动Docker并加入当前用户组避免每次docker命令加sudo sudo systemctl enable docker sudo systemctl start docker sudo usermod -aG docker $USER # 此时需退出终端重新登录或执行 newgrp docker 刷新组权限提示别跳过usermod -aG docker $USER这步。我见过太多人卡在这反复报错“Permission denied while trying to connect to the Docker daemon socket”本质就是用户没加入docker组。执行完记得新开一个终端窗口或运行newgrp docker。接着安装Docker Compose v2注意是v2不是已废弃的v1# 下载最新版Compose二进制文件截至2024年中最新稳定版是2.24.7 sudo curl -L https://github.com/docker/compose/releases/download/v2.24.7/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose # 验证安装 docker-compose --version最后创建一个专属工作目录并拉取multica官方仓库注意使用官方GitHub非第三方镜像mkdir -p ~/multica-deploy cd ~/multica-deploy git clone https://github.com/multica-org/multica.git cd multica # 查看最新稳定发布版避免用main分支的不稳定代码 git tag --sort-v:refname | head -n 1 # 假设输出是v1.3.0则检出该版本 git checkout v1.3.0此时你的目录结构应该是~/multica-deploy/multica/ ├── docker-compose.yml # 主编排文件 ├── .env # 环境变量模板 ├── docs/ # 官方文档 └── examples/ # 示例Agent配置3.2 配置文件详解与关键参数调优multica的部署核心是docker-compose.yml和.env两个文件。我们逐行拆解重点讲那些文档里没写清楚、但实际部署必调的参数。先看.env文件复制.env.example并编辑# 基础配置 # 项目名称影响Docker容器前缀建议用小写字母短横线 PROJECT_NAMEmultica-prod # 协调内核监听端口对外暴露给User Gateway COORDINATOR_PORT8000 # 数据库配置PostgreSQL用于状态存储 # 这里填你自己的PostgreSQL连接串如果用Docker部署可直接用service名 DB_HOSTpostgres DB_PORT5432 DB_NAMEmultica_state DB_USERmultica DB_PASSWORDyour_strong_password_here # 日志配置Elasticsearch用于日志分析 # 同样如果ES也用Docker这里填es ES_HOSTes ES_PORT9200 ES_INDEX_PREFIXmultica # Agent路由策略关键决定任务如何分发 # 可选值keyword_match按任务关键词匹配Agent、round_robin轮询、least_busy负载最低 ROUTING_STRATEGYkeyword_match # 安全配置 # JWT密钥必须更换用openssl生成32字节随机密钥 JWT_SECRETyour_32_byte_secret_key_here_replace_now # 生成命令openssl rand -hex 32注意JWT_SECRET必须更换我见过太多人直接用示例密钥上线结果被自动化扫描工具爆破所有API都能未授权调用。生成命令就在注释里复制粘贴执行即可。再看docker-compose.yml的核心片段已精简无关内容version: 3.8 services: # 协调内核 coordinator: image: multicaorg/coordinator:v1.3.0 ports: - ${COORDINATOR_PORT}:8000 environment: - DB_HOST${DB_HOST} - DB_PORT${DB_PORT} - DB_NAME${DB_NAME} - DB_USER${DB_USER} - DB_PASSWORD${DB_PASSWORD} - ES_HOST${ES_HOST} - ES_PORT${ES_PORT} - ROUTING_STRATEGY${ROUTING_STRATEGY} - JWT_SECRET${JWT_SECRET} depends_on: - postgres - es restart: unless-stopped # 用户网关 gateway: image: multicaorg/gateway:v1.3.0 ports: - 8080:8000 # 对外暴露8080端口 environment: - COORDINATOR_URLhttp://coordinator:8000 - JWT_SECRET${JWT_SECRET} depends_on: - coordinator restart: unless-stopped # 示例Agent库存查询 agent-inventory: image: multicaorg/agent-inventory:v1.3.0 environment: - MODEL_NAMEqwen2:7b # 指定Ollama模型名 - OLLAMA_HOSThost.docker.internal:11434 # 关键Mac/Windows用host.docker.internalLinux用宿主机IP - MAX_TOKENS2048 - TEMPERATURE0.3 # Linux下必须显式配置网络让容器能访问宿主机Docker extra_hosts: - host.docker.internal:172.17.0.1 # 这是Docker0网桥默认IP务必确认 restart: unless-stopped # PostgreSQL状态库 postgres: image: postgres:15-alpine environment: - POSTGRES_DB${DB_NAME} - POSTGRES_USER${DB_USER} - POSTGRES_PASSWORD${DB_PASSWORD} volumes: - ./data/postgres:/var/lib/postgresql/data restart: unless-stopped # Elasticsearch日志库 es: image: docker.elastic.co/elasticsearch/elasticsearch:8.12.2 container_name: es environment: - discovery.typesingle-node - xpack.security.enabledfalse - ES_JAVA_OPTS-Xms512m -Xmx512m ulimits: memlock: soft: -1 hard: -1 volumes: - ./data/es:/usr/share/elasticsearch/data restart: unless-stopped最关键的配置在agent-inventory服务的extra_hosts和OLLAMA_HOST。很多新手在Ubuntu上部署失败就是因为没配extra_hosts。Docker容器默认无法通过localhost访问宿主机必须用host.docker.internal这个特殊域名而Linux版Docker不原生支持它需要手动映射。172.17.0.1是Docker0网桥的默认IP但如果你改过Docker配置得用ip addr show docker0 | grep inet 确认。我建议你执行这条命令查准ip addr show docker0 | grep inet | awk {print $2} | cut -d/ -f1输出就是你要填的IP。填错会导致Agent启动后一直报“Connection refused to ollama”因为根本连不上。3.3 启动全流程与首次任务验证配置完成后一键启动# 在multica根目录下执行 docker-compose up -d # 查看服务状态等待1-2分钟ES和Postgres启动较慢 docker-compose ps # 应该看到所有服务状态为Up (healthy)特别关注coordinator和gateway # 如果某个服务是Up (unhealthy)或Restarting立刻看日志 docker-compose logs -f coordinator启动成功后用curl发一个最简单的测试任务# 构造一个JSON任务让库存Agent查SKU为ABC123的商品 curl -X POST http://localhost:8080/v1/tasks \ -H Content-Type: application/json \ -H Authorization: Bearer $(echo -n test_user:multica | base64) \ -d { task_type: inventory_check, input: {sku: ABC123}, timeout: 30 }注意这里的Authorization是Basic认证用户名密码是test_user:multicaBase64编码后填入。正式环境请换用JWT Token但测试用这个最简单。如果返回类似这样的JSON说明全链路跑通{ task_id: task_abc123_456, status: completed, result: { sku: ABC123, available_quantity: 42, warehouse: SHANGHAI_WAREHOUSE }, execution_time_ms: 1245 }此时你可以去PostgreSQL里查状态表验证# 进入PostgreSQL容器 docker-compose exec postgres psql -U multica multica_state # 查询任务快照 SELECT id, task_id, agent_name, input_json, output_json, created_at FROM task_snapshots WHERE task_id task_abc123_456;你会看到一条记录input_json是你发的{sku: ABC123}output_json是Agent返回的库存数据。这证明状态存储已生效。3.4 添加第二个Agent物流跟踪实现真协同单Agent只是玩具协同才是multica的价值。我们快速添加一个物流Agent让它和库存Agent一起工作。下载物流Agent镜像官方已提供docker pull multicaorg/agent-shipping:v1.3.0修改docker-compose.yml在services下新增agent-shipping: image: multicaorg/agent-shipping:v1.3.0 environment: - MODEL_NAMEqwen2:7b - OLLAMA_HOSThost.docker.internal:11434 - MAX_TOKENS2048 extra_hosts: - host.docker.internal:172.17.0.1 restart: unless-stopped重启服务docker-compose down docker-compose up -d发一个协同任务注意task_type现在是order_fulfillment会同时触发库存和物流curl -X POST http://localhost:8080/v1/tasks \ -H Content-Type: application/json \ -H Authorization: Bearer $(echo -n test_user:multica | base64) \ -d { task_type: order_fulfillment, input: {order_id: ORD789, sku: ABC123}, timeout: 45 }返回结果会是合并后的JSON包含库存和物流两部分数据。此时打开Coordinator的日志docker-compose logs -f coordinator | grep order_fulfillment你会看到类似coordinator_1 | INFO: Routing task order_fulfillment to agents: [agent-inventory, agent-shipping] coordinator_1 | INFO: Received result from agent-inventory for task ORD789 coordinator_1 | INFO: Received result from agent-shipping for task ORD789 coordinator_1 | INFO: Aggregated result for task ORD789, status: completed这就是协同的实感——两个Agent并行工作Coordinator只管分发和聚合不干涉内部逻辑。你甚至可以单独停掉agent-shipping再发任务Coordinator会自动降级只返回库存数据并在日志里记一笔agent-shipping unavailable, skipping。4. 协同能力深度解析意图对齐、资源仲裁与失败回滚的实现原理4.1 意图对齐如何让不同Agent理解同一任务的语义多Agent系统最大的隐形杀手不是技术故障而是语义误解。比如用户说“帮我查下这个订单能不能发货”库存Agent理解为“查SKU是否有货”物流Agent却理解为“查该地区是否在配送范围内”支付Agent可能去查“订单是否已付款”。如果它们各自返回“是/否”Coordinator怎么合并说“能发货”需要三个条件同时满足但没人告诉Coordinator这个业务规则。multica的解法是任务契约Task Contract。它不是一个空泛的JSON Schema而是一套带业务语义的YAML定义存放在examples/contracts/目录下。以order_fulfillment.yaml为例name: order_fulfillment description: 判断订单是否满足发货条件 input_schema: type: object properties: order_id: type: string description: 订单唯一标识 sku: type: string description: 商品SKU用于查库存 # 关键定义每个Agent的职责和输出约束 agents: - name: agent-inventory role: check_inventory_availability output_schema: type: object properties: available_quantity: type: integer minimum: 0 warehouse: type: string required: [available_quantity, warehouse] # 业务规则只有available_quantity 0才算通过 success_condition: output.available_quantity 0 - name: agent-shipping role: check_shipping_eligibility output_schema: type: object properties: is_eligible: type: boolean delivery_days: type: integer minimum: 1 required: [is_eligible, delivery_days] success_condition: output.is_eligible true # 最终聚合规则所有Agent都成功且满足业务逻辑 aggregation_rule: | if inventory.success and shipping.success: return { can_ship: True, estimated_delivery: shipping.output.delivery_days, warehouse: inventory.output.warehouse } else: return { can_ship: False, reasons: [ inventory.error if not inventory.success else None, shipping.error if not shipping.success else None ] }当你发order_fulfillment任务时Coordinator不是盲目转发而是解析input_schema校验order_id和sku是否存在且合法根据agents列表分别构造两个子任务一个给agent-inventory一个给agent-shipping每个子任务都附带role和output_schemaAgent执行后Coordinator用success_condition表达式实时判断结果是否达标比如output.available_quantity 0最后用aggregation_rule里的Python代码块合并结果。这个设计让“协同”有了业务根基。你不用在Coordinator代码里硬编码if-else只需改YAML文件。上线新业务新增一个contract文件写清输入、各Agent职责、成功条件、聚合逻辑重启Coordinator即可。我们上线一个跨境退税功能就是这么干的从写契约到上线只用了2小时。4.2 资源仲裁如何防止10个Agent同时打爆数据库当并发请求上来10个agent-inventory实例可能同时执行SELECT * FROM inventory WHERE sku ?如果没限制数据库连接池瞬间耗尽所有请求排队P99延迟飙升到10秒以上。multica的资源仲裁器Resource Arbiter不依赖外部中间件而是嵌在Coordinator里用两级限流第一级Agent级并发控制在docker-compose.yml里为每个Agent服务加deploy.resources.limitsagent-inventory: # ... 其他配置 deploy: resources: limits: cpus: 0.5 memory: 2G这限制了单个Agent容器最多用0.5核CPU和2G内存超了会被Linux OOM Killer干掉保护宿主机。第二级任务级连接池管理Coordinator为每个Agent类型维护一个连接池计数器。比如agent-inventory的最大并发数设为5可在.env里配AGENT_INVENTORY_MAX_CONCURRENCY5。当第6个库存查询任务来时Coordinator不立即转发而是把它放进一个优先队列按timeout倒序排列同时返回HTTP 429 Too Many Requests给用户并带Retry-After: 2头。用户SDK收到后2秒后重试。这比让任务在Agent里排队更公平——Agent只处理它能处理的任务Coordinator负责全局调度。我们在压测时对比过不启用仲裁100并发下数据库错误率35%启用后错误率降到0%P95延迟稳定在800ms以内。关键是这个仲裁是可配置、可关闭的。开发环境你可以设成100线上环境再调回5一切都在配置文件里不用改代码。4.3 失败回滚当Agent挂了系统如何优雅降级Agent系统不可能100%可靠。模型OOM、网络抖动、Ollama崩溃都会导致Agent失联。multica的失败处理不是简单重试而是三级降级策略一级超时熔断Coordinator给每个子任务设硬超时默认15秒。超时后立即标记该Agent为“临时不可用”未来30秒内不再给它派新任务这个时间可配。同时如果该Agent不是关键路径比如物流Agent挂了但库存和支付都OKCoordinator会按aggregation_rule里的逻辑用None或默认值填充其输出继续聚合。二级缓存兜底在examples/contracts/里可以为Agent配置fallback_cache_ttl缓存TTL。比如库存Agent的缓存设为300秒当它挂了Coordinator会查Redismultica内置Redis客户端返回5分钟前的库存快照并在返回JSON里加source: cache字段让用户知道这是兜底数据。三级人工接管当所有自动降级都失败Coordinator会触发escalation_hook——一个可配置的Webhook URL。比如发一个企业微信消息给值班工程师“订单ORD789的agent-shipping连续5次超时请检查Ollama服务”。这个Hook是异步的不影响主流程。我们线上用的就是这套组合拳。去年双十一Ollama服务因GPU显存不足崩溃持续12分钟。multica自动切换到缓存数据P99延迟只上升了200ms所有订单仍能正常流转运维同学是在告警群里看到消息后从容地SSH上去重启Ollama全程用户无感知。5. 实战避坑指南那些官方文档绝不会写的血泪教训5.1 Ollama模型加载慢别怪multica先查你的磁盘IO很多人反馈“部署完multica第一次调用库存Agent要等40秒”日志里全是waiting for ollama to load model qwen2:7b。这不是multica的问题是Ollama的模型加载机制。qwen2:7b模型文件约4.2GBOllama默认从~/.ollama/models加载如果这个目录在机械硬盘或云盘上顺序读取4GB文件自然慢。解决方案把Ollama模型目录挂载到SSD分区。假设你的SSD挂载在/mnt/ssd# 创建目录并赋权 sudo mkdir -p /mnt/ssd/ollama sudo chown -R 1001:1001 /mnt/ssd/ollama # Ollama容器默认用户UID是1001 # 修改docker-compose.yml为ollama服务加卷挂载 ollama: # ... 其他配置 volumes: - /mnt/ssd/ollama:/root/.ollama实测效果加载时间从40秒降到3秒。记住Ollama的性能瓶颈永远是磁盘不是CPU。5.2 macOS上Agent连不上Ollamahost.docker.internal不是万能的macOS的Docker Desktop确实支持host.docker.internal但有个隐藏坑它只在Docker Desktop 4.18版本才稳定。如果你用的是老版本curl http://host.docker.internal:11434/api/tags会返回Connection refused。终极解法不用host.docker.internal改用宿主机的真实IP。在macOS终端执行# 获取宿主机IP通常是en0接口 ipconfig getifaddr en0 # 输出类似 192.168.1.100然后在docker-compose.yml里把OLLAMA_HOST改成这个IPenvironment: - OLLAMA_HOST192.168.1.100:11434同时确保Ollama服务监听所有IP不只是localhost# 启动Ollama时加 --host 0.0.0.0:11434 ollama serve --host 0.0.0.0:11434Windows同理用ipconfig查Ethernet adapter Ethernet下的IPv4地址。5.3 PostgreSQL启动失败别急着重装先看磁盘空间docker-compose up后postgres服务一直Restarting日志里报No space left on device。这不是PostgreSQL配置问题是Docker的overlay2存储驱动占满了根分区。快速诊断# 查看Docker磁盘使用 docker system df -v # 查看根分区剩余空间 df -h / # 查看哪些容器日志最大常是罪魁祸首 sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -hr | head -20清理方案安全无损# 清理停止的容器、无用网络、悬空镜像 docker system prune -f # 清理所有构建缓存安全重建时会重新生成 docker builder prune -f # 限制单个容器日志大小永久生效加到daemon.json echo {log-driver:json-file,log-opts:{max-size:10m,max-file:3}} | sudo tee /etc/docker/daemon.json sudo systemctl restart docker我们线上服务器就因日志没限制半年后/var/lib/docker占满1TB磁盘整个系统卡死。加了日志限制后再没发生过。5.4 如何调试Agent内部逻辑别只会看Coordinator日志Coordinator日志只能告诉你“哪个Agent挂了”但查不出“为什么挂”。真正的调试必须进Agent容器内部。以agent-inventory为例# 进入容器 docker-compose exec agent-inventory sh # 查看Agent进程和端口 ps aux | grep python netstat -tuln | grep :8000 # 查看Ollama连接状态 curl -v http://host.docker.internal:11434/api/tags # 查看Agent自己的日志文件通常在/app/logs/ ls -l /app/logs/ tail -f /app/logs/inventory_agent.log你会发现Agent日志比Coordinator详细十倍模型加载进度、每次prompt的token数、工具调用的SQL语句、数据库返回的原始结果。有一次我们发现库存Agent总是返回available_quantity: 0进去一看是它生成的SQL里WHERE sku ?参数没绑定始终查NULL日志里清清楚楚写着Executing query: SELECT * FROM inventory WHERE sku NULL。这种问题Coordinator日志里永远看不到。5.5 生产环境必须做的三件事部署到生产光跑通不够这三件事不做等于裸奔HTTPS强制重定向docker-compose.yml里gateway服务只暴露HTTP必须前置Nginx做SSL终止。配置片段server {

相关新闻