Agent时代：模型是 Agent，代码是 Harness

第13篇 | Agent 时代模型是 Agent代码是 Harness本系列完。前12篇我们一直在拆解技术循环怎么转、工具怎么接、上下文怎么管、团队怎么协作。这一篇往后退一步聊聊技术之外的事。Agent 不是一个遥远的概念。Claude Code、Cursor、Devin、各种 coding agent 已经在真实的工程团队里投入使用了。Github Copilot 的月活跃用户早就过了百万。这些工具正在改变软件开发的工作方式——而且这只是开始。对于不同角色的人来说Agent 时代的到来意味着不同的事情。与其空泛地谈AI 改变世界不如具体地说它改变了你的什么你应该做什么准备对技术人员Harness 工程是新的核心竞争力你写的代码不会消失它会变形如果你是程序员过去一年你大概已经反复听到AI 会替代程序员的说法。这个说法对了一半AI 确实在替代部分编码工作——写 CRUD、实现简单逻辑、做格式转换这些事模型已经做得又快又好。但整个系列文章告诉你的另一件事是模型需要 Harness 才能干活。谁来造 Harness程序员。只是造的东西变了。以前你写的是业务逻辑代码以后你写的至少有一部分是 Agent 的驾驶舱给模型设计工具接口管理上下文窗口设定权限边界编排多 Agent 协作这些工作需要对模型的能力和局限有深入理解需要系统设计能力需要对安全和可靠性的敏感度。这不是更低级的工作恰恰是更高级的。该学什么具体一点Harness 工程的核心能力栈包括工具设计。怎么把一个复杂的系统暴露成模型能理解、能正确调用的工具集工具的粒度怎么定描述怎么写错误怎么返回这些问题的答案直接决定了 Agent 的能力上限。上下文管理。模型的上下文窗口是有限的资源。什么信息该在系统提示里什么信息该按需加载什么时候该压缩压缩后怎么保证连贯性——这是一门新的内存管理。权限控制。你不能让 Agent 拥有无限权力。哪些操作需要人工审批哪些路径是禁区危险命令怎么识别和拦截权限设计做不好轻则浪费钱重则出安全事故。多 Agent 协调。当一个 Agent 不够用需要多个协作时通信机制、任务分配、冲突隔离这些问题就冒出来了。这本质上就是分布式系统设计只不过节点换成了 LLM。心态上怎么调整不排斥也不恐慌。不排斥——Agent 不是敌人是你的新搭档。抵触它只会让你错过学习窗口。不恐慌——Agent 的能力增长虽然快但它现在还做不到自己决定要造什么。它能执行你的意图但定义意图的还是你。就像 s_full.py 里的模型可以自主选择工具、自主规划步骤但系统提示、工具清单、权限边界全是人定义的。你的角色从写代码的人逐渐变成设计 Agent 能力边界的人。这个转变已经在发生越早适应越好。对非技术人员做更好的需求方Agent 能做什么不能做什么经过前面12篇的学习你应该对 Agent 的能力有了务实的认知它能做的多步骤、有规则的复杂任务比如按照这个规范重构代码需要大量信息检索和汇总的工作比如分析这10个文件的依赖关系重复性高、模式明确的操作比如给每个函数加上文档注释它不能做的需要人类价值判断的决策“这个功能值不值得做”需要理解未表述的隐含需求“老板说的’简单改一下’到底是什么意思”需要物理世界交互的操作至少目前还不行需要跨组织政治敏感度的沟通Agent 不懂这封邮件要抄送给谁的潜规则你的指令就是 Agent 的系统提示这个系列反复出现一个概念系统提示决定了模型的行为模式。对你来说你给 Agent 下的指令就是它的系统提示。指令越清晰、越具体、越有边界感Agent 的产出质量越高。差的指令“帮我写个方案。”好的指令“帮我写一个季度复盘报告的框架。包括三个部分目标达成情况、遇到的主要问题、下季度改进计划。每部分列3-5个要点每个要点一句话。用中文语气正式但不套话。”你会发现这和给人下需求是一样的道理。一个好的需求描述不管对面坐的是人还是 Agent都会产出更好的结果。它更像一个新同事不要把 Agent 当工具用把它当一个有能力但需要指导的新同事。你不会对一个工具说你觉得这样合适吗“但你可以对 Agent 说。你不会要求一个工具先列个方案让我看看再做”但你应该对 Agent 这么要求。s10 里的计划审批协议本质上就是先出方案审批通过再执行。你在和 Agent 协作时也应该建立这样的习惯。对管理者怎么评估、怎么引入、怎么算账什么任务适合交给 Agent三个判断标准重复性高。每次操作的模式类似只是具体参数不同。典型例子日常报告生成、数据格式转换、代码审查。规则明确。什么情况做什么有清晰的定义不需要凭感觉判断。典型例子按照规范做代码重构、根据模板填写文档。有工具可接入。Agent 的能力取决于它有什么工具。如果操作对象是数字化的代码、文档、数据库、APIAgent 就能接入。如果需要打电话、走线下流程Agent 帮不上忙。三条都满足的任务是 Agent 的最佳应用场景。满足两条的可以尝试。只满足一条的谨慎考虑。怎么引入从小场景试点。不要一上来就全面 AI 化。找一个具体的、可衡量的场景跑一个月看效果。比如让 Agent 帮 QA 团队写自动化测试用例看看产出质量和人工写的差多少、节省了多少时间。积累经验逐步扩大。第一个场景跑通了团队会形成对 Agent 的务实认知——它擅长什么、不擅长什么、需要什么条件。带着这些经验去评估下一个场景成功率会高很多。安排专人负责。Agent 不是接上 API 就能用的东西。工具设计、提示词调优、权限配置、异常处理——这些都需要人持续跟进。至少安排一个对模型能力有理解的人来负责。成本怎么算API 调用是有成本的。一次复杂任务可能调用模型几十次每次消耗几千个 token。按 Claude Sonnet 的定价一个中等复杂度的任务大约花费几元到十几元人民币。贵吗要看和什么比。如果一个工程师花两小时做的事Agent 花两分钟 十块钱就搞定了那绝对划算。但如果 Agent 反复出错、需要人工反复修正总成本可能比直接让人做还高。所以试点阶段的数据收集很重要。记录每个任务的 API 花费、完成时间、人工介入次数用数据说话。从按需使用到永远在线目前大多数人使用 Agent 的模式是按需启动你有需求了打开 Claude Code给它一个任务它完成后你关掉。这是 s01 到 s_full 讲的模式。但这不是终态。永远在线的 Agent想象一个 Agent 不是你打开的而是一直在那里的。它每隔30秒醒来一次heartbeat检查有没有新任务。它能自己安排未来的工作类似 cron 定时任务。它在各种沟通渠道上工作——Slack、飞书、邮件——哪里有人 它它就在哪里响应。这不是科幻。一些团队已经在用这种模式了监控 Agent每5分钟检查一次服务健康状态发现异常自动排查并通知代码审查 Agent每当有新的 Pull Request自动审查并留下评论数据分析 Agent每天早上自动生成昨日数据报告发到群里从人找 Agent变成Agent 找活这是 s11 自治 Agent 思想的自然延伸。区别只是规模——s11 是在一个项目内找任务而永远在线的 Agent 是在整个工作流里找任务。多渠道接入Agent 的接口不一定是终端命令行。它可以是飞书/Slack 里的一个机器人你 它说帮我查一下昨天的线上错误数邮件里的一个收件人你把需求写在邮件正文里发给它一个 API endpoint你的其他系统通过 HTTP 调用它底层的 Agent Loop 不变变的只是输入输出的通道。这正是 Harness 设计的魅力——核心机制与接入方式解耦。结尾模型是 Agent代码是 Harness这个系列从第一篇开始就在强调一个核心观点模型本身就是 Agent。它有理解能力、推理能力、规划能力、工具使用能力。程序员的工作不是让模型变成 Agent而是给它造一个合适的 Harness——一个驾驶舱——让它的能力得以施展。13篇文章我们从最简单的 while 循环出发一步步叠加了工具、计划、技能、上下文管理、任务系统、多 Agent 团队、通信协议、自治机制、目录隔离最终拼出了一个完整的 Agent 系统。每一个机制单独看都不复杂。它们的价值在于组合在于叠加。就像这个系列反复出现的第一条设计哲学——循环不变机制叠加。Agent 时代已经开始了。不管你是写代码的、提需求的、还是做决策的理解 Agent 的工作原理都会让你更好地和它协作。造好 HarnessAgent 会完成剩下的事。本系列完。项目地址learn-claude-code —— 所有代码可直接 clone 运行。