本文详细记录了从单机到多Agent协作的生产落地过程包括原理介绍、实现步骤以及四个真实踩坑实录。通过学习本文你将了解到多Agent协作的必要性、实现方法以及如何避免常见问题从而在生产环境中高效运用Harness。Harness 生产落地从单机到多 Agent 协作的踩坑实录一、原理单机到多 Agent 的三道坎1 为什么一个进程跑多 Agent行不通很多人包括我们最初的设计是这样的单进程多 Profile 方案 ├── Profile: code-reviewer评代码 ├── Profile: test-runner跑测试 └── Profile: doc-writer写文档 共享一个 Cordis Context理论上很美好三个 Agent 共享文件系统、共享 git、共享模型客户端开销低、通信简单。实际上线后第二天就出问题了现象原因Agent A 卸载时把 B 的临时文件也清了Proxy 副作用清理是按插件 scope 隔离的但文件系统是共享的Agent A 改了 configB 拿到的还是旧值配置层是全局的没有 per-agent 隔离一个 Agent 死循环整个进程崩了没有进程级隔离单点故障拖垮全局调试时不知道是哪个 Agent 在做事日志共用一个 stdout分不开关键结论单进程多 Profile 适合一个 Agent 多身份比如同一个 Agent 切换工具集不适合多个独立 Agent 协作。后者必须上进程隔离。2 真正的多 Agent 协作需要什么生产环境的多 Agent 协作至少要解决三件事状态隔离每个 Agent 有自己的 Context、Proxy、配置——A 的副作用不影响 B。通信标准化Agent 之间不共享内存通过消息总线通信——和微服务一个逻辑。故障隔离A 崩了B 和 C 不受影响——这是单进程方案做不到的。Harness 提供了dsh swarm模式来支持这个但默认配置不够用下面逐条讲怎么调。3 协作模式的选择多 Agent 协作不是只有一种模式。Harness 支持三种主流模式各有适用场景模式适用不适用主从编排任务可分解、有明确编排逻辑Agent 之间需要平等协商事件驱动流水线场景A→B→C需要全局决策黑板模式探索性任务、协同设计强一致性的场景我们的真实教训最初用了主从编排但代码评审场景里评审 Agent和测试 Agent经常需要互相质疑评审说这个函数太长测试说但测试覆盖率上来了主从模式处理不了这种平等协商最后切到了黑板模式。二、实现搭建一个三 Agent 协作系统1 进程拓扑下面是我们线上跑的真实架构三个 Agent 各自是独立的 dsh 进程由dsh-swarm编排通过 Redis Pub/Sub 通信共享状态放在 SQLite。2 最小可运行的 swarm 配置项目根目录放一个swarm.yml# swarm.yml name: code-automation version: 1 # 共享状态存储 state: type: sqlite path: ./state/shared.db # 消息总线 bus: type: redis url: redis://localhost:6379/0 # Agent 定义 agents: - name: reviewer profile: ./profiles/reviewer plugins: - deepseek-model - git - fs subscriptions: - git:commit - test:done publishes: - review:done - review:blocked - name: tester profile: ./profiles/tester plugins: - deepseek-model - git - shell subscriptions: - review:done publishes: - test:done - test:failed - name: doc-writer profile: ./profiles/doc-writer plugins: - deepseek-model - fs subscriptions: - test:done publishes: - doc:done启动dsh swarm start --config swarm.ymldsh-swarm会拉起三个子进程每个装载自己的 Profile 和 Plugin互相通过 Redis 通信。3 Agent 之间怎么通信通信完全靠事件不直接调用。比如 reviewer Agent 评审完发个事件// reviewer 插件内 export const name reviewer export const inject [bus, model, git] export async function apply(ctx: Context) { ctx.on(git:commit, async (session) { const diff await ctx.git.diff() const review await ctx.model.chat({ system: You are a code reviewer., user: Review: ${diff}, }) // 写共享状态 await ctx.state.set(last-review, { commit: session.commitHash, result: review, timestamp: Date.now(), }) // 发事件通知其他 Agent await ctx.bus.emit(review:done, { commit: session.commitHash, blocked: review.includes(BLOCKED), }) }) }tester Agent 收到事件后开跑// tester 插件内 export const name tester export const inject [bus, state, shell] export async function apply(ctx: Context) { ctx.on(review:done, async (event) { if (event.blocked) { // 评审说有问题不跑测试 await ctx.bus.emit(test:skipped, { reason: review blocked }) return } const result await ctx.shell.exec(npm test) await ctx.state.set(last-test, { result }) await ctx.bus.emit(test:done, { passed: result.exitCode 0, coverage: parseCoverage(result.stdout), }) }) }注意三个关键点不直接调用reviewer 不 import tester只发事件。这让两个 Agent 可以独立部署、独立迭代。共享状态用ctx.state不是直接写文件或 Redis而是走 Cordis 的 state 抽象——底层实现可以是 SQLite/Redis/内存插件代码不变。事件名约定用domain:action格式如review:done避免命名冲突。4 调试技巧怎么看 Agent 在做什么多 Agent 系统最大的痛点是调试——三个进程各跑各的出了问题不知道谁先动的手。Harness 提供了一个dsh swarm trace命令能按时间线展示所有事件流dsh swarm trace --last 1h # 输出示例 [15:01:23] git:commit → reviewer [15:01:24] reviewer.start (running 4.2s) [15:01:28] review:done → tester [15:01:29] tester.start (running 18.7s) [15:01:47] test:done → doc-writer [15:01:48] doc-writer.start (running 6.1s) [15:01:54] doc:done这比看三个独立日志直观得多。出问题时一眼能看出卡在哪。三、落地生产环境四个真实踩坑实录1 坑一Agent 之间消息风暴现象reviewer 发review:donetester 收到后跑测试发test:failed。reviewer 订阅了test:failed触发新一轮评审又发review:done……形成死循环。10 分钟内 Redis 队列堆了 4 万条消息。原因事件订阅没有去重没有终止条件。Agent A 的事件触发 BB 的事件又触发 A形成正反馈循环。解法每个事件加trace_id和attempt字段订阅方判断是否要处理ctx.on(test:failed, async (event) { if (event.attempt 3) { await ctx.bus.emit(review:giveup, { reason: too many retries }) return } // 继续 retry })发事件时递增 attemptawait ctx.bus.emit(review:done, { commit: session.commitHash, attempt: (event.attempt || 0) 1, trace_id: event.trace_id, // 同一条链路保持一致 })2 坑二共享状态写冲突现象tester 和 doc-writer 同时往state/shared.db写数据SQLite 报database is locked。原因SQLite 不支持并发写。多 Agent 同时写共享状态必然冲突。解法换成 Redis 做共享状态支持并发写SQLite 只做持久化归档state: type: redis url: redis://localhost:6379/1 archive: type: sqlite path: ./state/archive.db interval: 5m # 每5分钟归档一次或者用 namespace 隔离每个 Agent 只写自己的 namespace// 每个插件用独立 namespace不互相干扰 const ns ctx.state.namespace(agent:${ctx.meta.id}) await ns.set(last-test, result)3 坑三单个 Agent 卡死拖垮全局现象doc-writer 调模型超时30 秒整个 swarm 卡住。后续的 commit 都没人响应。原因默认配置下Agent 处理事件是串行的——一个事件没处理完下一个排队等。如果 Agent 卡死所有订阅同一事件的其他 Agent 也会饿死。解法给每个 Agent 设并发数和超时agents: - name: doc-writer profile: ./profiles/doc-writer concurrency: 3 # 同时处理 3 个事件 timeout: 60s # 单事件超时 retry: max_attempts: 2 backoff: exponential同时给 swarm 加健康检查health: check_interval: 30s on_unhealthy: restart # Agent 卡死就重启 max_restarts: 5 # 一小时内重启超过5次告警4 坑四日志和监控现象三个 Agent 各自写日志到./logs/agent-{name}.log出问题时要切三个文件查且时间戳对不齐。原因默认配置每个 Agent 独立 stdout没有统一聚合。解法用结构化日志 统一聚合。在swarm.yml加logging: format: json outputs: - type: file path: ./logs/swarm.log - type: loki url: http://loki:3100 fields: trace_id: true # 自动注入 trace_id agent_name: true event_name: true这样所有日志都进同一个文件每行带agent_name和trace_id方便 grep 和聚合# 看某个 trace 的完整链路 cat logs/swarm.log | jq select(.trace_id /abc-123/) # 看某个 Agent 的所有日志 cat logs/swarm.log | jq select(.agent_name /reviewer/)四、成本与适用性什么时候用什么时候别用写到这里该说真话了——Harness 的多 Agent 协作不是银弹跟 Agent 系列 03 篇讲的一样要权衡。1 适合 Harness 多 Agent 的场景场景为什么适合代码评审 测试 文档链天然流水线事件驱动很自然多模型对比A 用 GPTB 用 ClaudeHarness 的模型即插件让切换零成本长期运行的后台 Agent监听 issue、PRCordis 的副作用可回滚在长期任务里特别值钱多租户 Agent 服务进程隔离天然支持2 不适合的场景场景为什么不适合单次简单问答上 swarm 是杀鸡用牛刀单 Agent 够了强一致性的交易系统事件驱动是最终一致不适合需要 ACID 的场景高频低延迟100ms跨进程通信 Redis 中转延迟天然在 100ms团队没人懂 TypeScript/Cordis学习曲线陡团队不熟容易踩坑3 一个判断公式借鉴 Agent 系列 03 的思路给个判断准则任务复杂度高 多专业协作 可接受最终一致性 → 上 Harness 多 Agent任务简单 单专业 需要强一致 → 用单 Agent 或传统架构收尾Harness 系列完结四篇写到这里Harness 系列就告一段落了。回顾一下篇主题层次01AGENT MODEL HARNESS 全景原理025 分钟跑起来 dsh实现03Cordis 内核 插件开发实现落地04多 Agent 协作生产落地落地如果你跟着四篇走下来应该已经能跑起来 Harness、写自己的插件、理解 Cordis 内核、在生产环境做多 Agent 协作。Harness 这个项目开源才一周截至本篇发布生态还很早期。但它的设计哲学——“一切皆插件 副作用可逆 进程隔离”——这些理念会慢慢渗透到整个 Agent 领域。提前理解这套东西无论你最后用不用 Harness都不亏。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 本文详细记录了从单机到多Agent协作的生产落地过程包括原理介绍、实现步骤以及四个真实踩坑实录。通过学习本文你将了解到多Agent协作的必要性、实现方法以及如何避免常见问题从而在生产环境中高效运用Harness。Harness 生产落地从单机到多 Agent 协作的踩坑实录一、原理单机到多 Agent 的三道坎1 为什么一个进程跑多 Agent行不通很多人包括我们最初的设计是这样的单进程多 Profile 方案 ├── Profile: code-reviewer评代码 ├── Profile: test-runner跑测试 └── Profile: doc-writer写文档 共享一个 Cordis Context理论上很美好三个 Agent 共享文件系统、共享 git、共享模型客户端开销低、通信简单。实际上线后第二天就出问题了现象原因Agent A 卸载时把 B 的临时文件也清了Proxy 副作用清理是按插件 scope 隔离的但文件系统是共享的Agent A 改了 configB 拿到的还是旧值配置层是全局的没有 per-agent 隔离一个 Agent 死循环整个进程崩了没有进程级隔离单点故障拖垮全局调试时不知道是哪个 Agent 在做事日志共用一个 stdout分不开关键结论单进程多 Profile 适合一个 Agent 多身份比如同一个 Agent 切换工具集不适合多个独立 Agent 协作。后者必须上进程隔离。2 真正的多 Agent 协作需要什么生产环境的多 Agent 协作至少要解决三件事状态隔离每个 Agent 有自己的 Context、Proxy、配置——A 的副作用不影响 B。通信标准化Agent 之间不共享内存通过消息总线通信——和微服务一个逻辑。故障隔离A 崩了B 和 C 不受影响——这是单进程方案做不到的。Harness 提供了dsh swarm模式来支持这个但默认配置不够用下面逐条讲怎么调。3 协作模式的选择多 Agent 协作不是只有一种模式。Harness 支持三种主流模式各有适用场景模式适用不适用主从编排任务可分解、有明确编排逻辑Agent 之间需要平等协商事件驱动流水线场景A→B→C需要全局决策黑板模式探索性任务、协同设计强一致性的场景我们的真实教训最初用了主从编排但代码评审场景里评审 Agent和测试 Agent经常需要互相质疑评审说这个函数太长测试说但测试覆盖率上来了主从模式处理不了这种平等协商最后切到了黑板模式。二、实现搭建一个三 Agent 协作系统1 进程拓扑下面是我们线上跑的真实架构三个 Agent 各自是独立的 dsh 进程由dsh-swarm编排通过 Redis Pub/Sub 通信共享状态放在 SQLite。2 最小可运行的 swarm 配置项目根目录放一个swarm.yml# swarm.yml name: code-automation version: 1 # 共享状态存储 state: type: sqlite path: ./state/shared.db # 消息总线 bus: type: redis url: redis://localhost:6379/0 # Agent 定义 agents: - name: reviewer profile: ./profiles/reviewer plugins: - deepseek-model - git - fs subscriptions: - git:commit - test:done publishes: - review:done - review:blocked - name: tester profile: ./profiles/tester plugins: - deepseek-model - git - shell subscriptions: - review:done publishes: - test:done - test:failed - name: doc-writer profile: ./profiles/doc-writer plugins: - deepseek-model - fs subscriptions: - test:done publishes: - doc:done启动dsh swarm start --config swarm.ymldsh-swarm会拉起三个子进程每个装载自己的 Profile 和 Plugin互相通过 Redis 通信。3 Agent 之间怎么通信通信完全靠事件不直接调用。比如 reviewer Agent 评审完发个事件// reviewer 插件内 export const name reviewer export const inject [bus, model, git] export async function apply(ctx: Context) { ctx.on(git:commit, async (session) { const diff await ctx.git.diff() const review await ctx.model.chat({ system: You are a code reviewer., user: Review: ${diff}, }) // 写共享状态 await ctx.state.set(last-review, { commit: session.commitHash, result: review, timestamp: Date.now(), }) // 发事件通知其他 Agent await ctx.bus.emit(review:done, { commit: session.commitHash, blocked: review.includes(BLOCKED), }) }) }tester Agent 收到事件后开跑// tester 插件内 export const name tester export const inject [bus, state, shell] export async function apply(ctx: Context) { ctx.on(review:done, async (event) { if (event.blocked) { // 评审说有问题不跑测试 await ctx.bus.emit(test:skipped, { reason: review blocked }) return } const result await ctx.shell.exec(npm test) await ctx.state.set(last-test, { result }) await ctx.bus.emit(test:done, { passed: result.exitCode 0, coverage: parseCoverage(result.stdout), }) }) }注意三个关键点不直接调用reviewer 不 import tester只发事件。这让两个 Agent 可以独立部署、独立迭代。共享状态用ctx.state不是直接写文件或 Redis而是走 Cordis 的 state 抽象——底层实现可以是 SQLite/Redis/内存插件代码不变。事件名约定用domain:action格式如review:done避免命名冲突。4 调试技巧怎么看 Agent 在做什么多 Agent 系统最大的痛点是调试——三个进程各跑各的出了问题不知道谁先动的手。Harness 提供了一个dsh swarm trace命令能按时间线展示所有事件流dsh swarm trace --last 1h # 输出示例 [15:01:23] git:commit → reviewer [15:01:24] reviewer.start (running 4.2s) [15:01:28] review:done → tester [15:01:29] tester.start (running 18.7s) [15:01:47] test:done → doc-writer [15:01:48] doc-writer.start (running 6.1s) [15:01:54] doc:done这比看三个独立日志直观得多。出问题时一眼能看出卡在哪。三、落地生产环境四个真实踩坑实录1 坑一Agent 之间消息风暴现象reviewer 发review:donetester 收到后跑测试发test:failed。reviewer 订阅了test:failed触发新一轮评审又发review:done……形成死循环。10 分钟内 Redis 队列堆了 4 万条消息。原因事件订阅没有去重没有终止条件。Agent A 的事件触发 BB 的事件又触发 A形成正反馈循环。解法每个事件加trace_id和attempt字段订阅方判断是否要处理ctx.on(test:failed, async (event) { if (event.attempt 3) { await ctx.bus.emit(review:giveup, { reason: too many retries }) return } // 继续 retry })发事件时递增 attemptawait ctx.bus.emit(review:done, { commit: session.commitHash, attempt: (event.attempt || 0) 1, trace_id: event.trace_id, // 同一条链路保持一致 })2 坑二共享状态写冲突现象tester 和 doc-writer 同时往state/shared.db写数据SQLite 报database is locked。原因SQLite 不支持并发写。多 Agent 同时写共享状态必然冲突。解法换成 Redis 做共享状态支持并发写SQLite 只做持久化归档state: type: redis url: redis://localhost:6379/1 archive: type: sqlite path: ./state/archive.db interval: 5m # 每5分钟归档一次或者用 namespace 隔离每个 Agent 只写自己的 namespace// 每个插件用独立 namespace不互相干扰 const ns ctx.state.namespace(agent:${ctx.meta.id}) await ns.set(last-test, result)3 坑三单个 Agent 卡死拖垮全局现象doc-writer 调模型超时30 秒整个 swarm 卡住。后续的 commit 都没人响应。原因默认配置下Agent 处理事件是串行的——一个事件没处理完下一个排队等。如果 Agent 卡死所有订阅同一事件的其他 Agent 也会饿死。解法给每个 Agent 设并发数和超时agents: - name: doc-writer profile: ./profiles/doc-writer concurrency: 3 # 同时处理 3 个事件 timeout: 60s # 单事件超时 retry: max_attempts: 2 backoff: exponential同时给 swarm 加健康检查health: check_interval: 30s on_unhealthy: restart # Agent 卡死就重启 max_restarts: 5 # 一小时内重启超过5次告警4 坑四日志和监控现象三个 Agent 各自写日志到./logs/agent-{name}.log出问题时要切三个文件查且时间戳对不齐。原因默认配置每个 Agent 独立 stdout没有统一聚合。解法用结构化日志 统一聚合。在swarm.yml加logging: format: json outputs: - type: file path: ./logs/swarm.log - type: loki url: http://loki:3100 fields: trace_id: true # 自动注入 trace_id agent_name: true event_name: true这样所有日志都进同一个文件每行带agent_name和trace_id方便 grep 和聚合# 看某个 trace 的完整链路 cat logs/swarm.log | jq select(.trace_id /abc-123/) # 看某个 Agent 的所有日志 cat logs/swarm.log | jq select(.agent_name /reviewer/)四、成本与适用性什么时候用什么时候别用写到这里该说真话了——Harness 的多 Agent 协作不是银弹跟 Agent 系列 03 篇讲的一样要权衡。1 适合 Harness 多 Agent 的场景场景为什么适合代码评审 测试 文档链天然流水线事件驱动很自然多模型对比A 用 GPTB 用 ClaudeHarness 的模型即插件让切换零成本长期运行的后台 Agent监听 issue、PRCordis 的副作用可回滚在长期任务里特别值钱多租户 Agent 服务进程隔离天然支持2 不适合的场景场景为什么不适合单次简单问答上 swarm 是杀鸡用牛刀单 Agent 够了强一致性的交易系统事件驱动是最终一致不适合需要 ACID 的场景高频低延迟100ms跨进程通信 Redis 中转延迟天然在 100ms团队没人懂 TypeScript/Cordis学习曲线陡团队不熟容易踩坑3 一个判断公式借鉴 Agent 系列 03 的思路给个判断准则任务复杂度高 多专业协作 可接受最终一致性 → 上 Harness 多 Agent任务简单 单专业 需要强一致 → 用单 Agent 或传统架构收尾Harness 系列完结四篇写到这里Harness 系列就告一段落了。回顾一下篇主题层次01AGENT MODEL HARNESS 全景原理025 分钟跑起来 dsh实现03Cordis 内核 插件开发实现落地04多 Agent 协作生产落地落地如果你跟着四篇走下来应该已经能跑起来 Harness、写自己的插件、理解 Cordis 内核、在生产环境做多 Agent 协作。Harness 这个项目开源才一周截至本篇发布生态还很早期。但它的设计哲学——“一切皆插件 副作用可逆 进程隔离”——这些理念会慢慢渗透到整个 Agent 领域。提前理解这套东西无论你最后用不用 Harness都不亏。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】