引言

前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 的能力取决于它有什么工具。如果操作对象是数字化的（代码、文档、数据库、API），Agent 就能接入。如果需要打电话、走线下流程，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 的工作原理都会让你更好地和它协作。

造好 Harness，Agent 会完成剩下的事。

本系列完。

项目地址：learn-claude-code —— 所有代码可直接 clone 运行。

Agent 时代，我们该怎么办

评论区

需要帮助？