AI 编码代理改变了我对软件开发的思考方式。
不久以前，当我想到在开发中使用 AI 时，我主要想到的是向模型提问、得到答案、复制一些代码，然后自己继续工作。
这种模式正在快速变化。
如今，AI 代理可以被赋予任务，检查代码库，修改文件，运行工具，调查错误，并继续朝着目标工作。
但这带来了一个新问题。
当 AI 不仅仅是助手，而是成为团队的一部分时，会发生什么？
如果一个开发者在任务上启动了一个代理，另一个开发者能否添加上下文？
有人能在代理工作时重定向它吗？
另一个人能否审查结果并继续任务？
工作能否在人与代理之间来回交接而不丢失上下文？
随着开发团队开始在人类开发者旁边同时运行多个 AI 代理，这些问题变得越来越重要。
挑战不在于仅仅让 AI 代理完成工作。
而是要弄清楚人类和代理如何协作，而不产生另一层脱节的对话、提示、终端和状态更新。
人类与代理协作实际上意味着什么？
我认为在 使用 AI 和 与 AI 代理协作 之间存在一个重要的区别。
当我让 ChatGPT 解释一个 API 时，这就是 AI 辅助。
当我让 AI 编码工具建议一个函数时，这也是辅助。
但代理的运作方式可能不同。
代理不需要等我逐条提供指令，它可以接受一个更广泛的目标，并朝着该目标执行多个步骤。
这改变了工作流程。
开发者可能会创建这样的任务：
为新的 API 端点添加身份验证，更新测试，并确保现有端点继续正常工作。
然后代理可以检查代码库，进行修改，运行测试，并报告发生的情况。
但开发者不一定会从过程中消失。
他们可能在进行到一半时意识到身份验证需求需要以不同的方式工作。
第二位开发者可能会注意到一种边界情况。
审阅者可能会要求额外的测试。
产品经理可能会修改验收需求。
代理需要对这些变化作出响应。
这就是我所说的人机协作。
人类并不是仅仅给代理一个提示然后等待最终答案。
人类和代理正在参与一项持续的工作。
多人能否加入同一个实时 AI-Agent 会话？
这是围绕基于代理的开发的最有趣的问题之一。
想象一下，一个开发者启动一个 AI 代理来开发一个功能。
代理完成了实施的一半。
另一位开发者查看任务后意识到，由于系统其他部分的限制，原始方法行不通。
在传统工作流程中，第二位开发者可能会给第一位开发者发消息，后者再返回终端告诉代理该怎么做。
这会产生大量不必要的交接。
更好的模型是将 任务本身作为共享上下文。
与其将代理会话视为某人的私人对话，团队可以将需求、讨论、执行历史和评审与同一项工作保持关联。
这是 Sharkly 核心理念之一。
Sharkly 将自己描述为一个面向人和代理的工作管理系统，其中需求、任务状态、讨论、执行记录和评审被保持在一起，而不是分散在私人提示和终端会话中。
这并不意味着每个人都必须在同一时刻在完全相同的聊天窗口中输入。
事实上，Sharkly 的文档在独立的 Agent Chat 与围绕任务发生的协作之间做了重要区分。
独立的 Agent Chat 属于创建该会话的人。基于任务的工作流则不同：任务成为人们可以围绕工作进行协作的共享记录。
这种区别很重要。
目标不一定是 “把所有人放进一个巨大的聊天中。”
目标是：
让所有人从同一个真相来源进行工作。
人类和代理如何协同工作
一个真实的开发工作流可能如下所示：
产品需求 → 人类规划 → 代理执行 → 人类反馈 → 代理调整 → 人类审查 → 完成
让我们使其更具体。
步骤 1：人员定义任务
开发人员或产品经理会创建一个描述需要完成内容的任务。
任务可以包含目标、描述、验收标准、优先级、状态以及其他项目信息。
在 Sharkly 中，任务还可以指定负责工作的人员，以及分配执行它的代理或团队。
步骤 2：代理开始工作
代理接收任务上下文并开始执行。
基于任务的运行可以包括任务描述、当前状态、项目和冲刺信息、最近的评论、代理指令、技能、仓库、环境配置和运行时设置。
这一点很重要，因为代理不仅仅是在孤立的单句话基础上运行。
它围绕工作拥有结构化的上下文。
步骤 3：人员添加上下文
在工作进行过程中，开发人员可能会意识到某件重要的事情：
"不要修改遗留的身份验证中间件。移动客户端仍然依赖它。"
这些信息需要成为工作的一部分。
在 Sharkly 中，任务评论正是为此类讨论而设计。评论可以包含新需求、约束、审查发现、决策、文件、截图，或针对任务的代理负责人的指令。
步骤 4：代理继续
该评论可以触发分配给该任务的代理的后续运行。
Sharkly 的执行模型允许符合条件的成员评论排队后续工作，即使另一个运行正在进行。系统可以合并待处理工作，以免快速评论为同一代理和任务创建重复的待处理运行。
这与每次需求变更时仅仅启动一个新的 AI 对话的模型截然不同。
步骤 5：另一人审查结果
代理完成。
现在有人需要查看发生了什么。
实现是否正确？
测试是否通过？
代理是否误解了需求？
是否有需要更改的地方？
代理可以将结果作为与其执行关联的 Task 评论留下，而执行日志则提供有关运行的附加信息。
然后，人类成为审查者，而不仅仅是等待 AI 输出的人。
为什么上下文正在成为项目管理问题
这可能是 AI 代理引入开发工作流的最大变化。
我们一直需要项目管理，因为软件开发涉及多个人员、任务、依赖、优先级和决策。
代理带来了另一个问题：
上下文连续性。
AI 代理可以产出好的工作，但仍可能因缺乏正确的上下文而失败。
也许需求发生了变化。
也许另一位开发者做出了相关的架构决策。
也许发现了边界情况。
也许之前的尝试失败了。
如果这些信息仅存在于某人的私聊或终端会话中，团队其他成员可能不知道。
这就是项目管理开始不仅仅是任务列表的地方。
任务可以成为工作的共享记忆。
在 Sharkly 中，Task 保存目标、状态、负责人、评论、附件、活动以及代理执行信息。
这为人和代理提供了一个可以返回的地方。
代理项目管理工具实际上应该做什么？
我认为这是 代理项目管理工具 的定义开始与传统项目管理软件不同的地方。
它不一定需要取代 Jira 风格工具所做的一切。
但它需要明白，代理能够实际执行工作。
以下是我会关注的一些能力。
1. 将工作分配给人类和代理
任务不应假设执行者始终是人。
系统应能够清晰地表示人类所有权和代理执行。
Sharkly 的任务模型支持 People、Agents 和 Crews 作为分配对象。
2. 保持上下文
代理需要访问相关任务信息，而不是每次都收到一个脱离上下文的提示。
这包括需求、评论、仓库、技能以及其他执行配置。
3. 保留执行历史
如果代理进行了更改，团队应能够了解发生了什么。
Sharkly 将任务工作流状态与代理运行状态分开，并保持诸如排队中、运行中、已完成、失败和已取消等执行信息。
4. 允许人类干预
代理不应作为黑箱运行。
人类应能够添加上下文、回答问题、提供更正、审查结果、停止运行、重试工作或重新分配任务。
Sharkly 的工作流支持后续评论、人类注意状态、取消、重试和重新分配。
5. 使交接成为可能
启动任务的人不一定是完成任务的人。
启动工作的代理也不一定是处理下一阶段的代理。
项目管理系统应使这些转变可见，而不是将其隐藏在私下对话中。
从单个代理到代理团队
当你停止只考虑一个代理时，下一步会变得更加有趣。
想象一个软件项目，其中不同的代理承担不同的职责。
一个代理负责实现。
另一个专注于测试。
另一个负责文档。
另一个调查生产问题。
现在问题变成：
你如何协调所有这些？
Sharkly 使用了 Crew 的概念。
Crew 将领导 Agent 与其他 Agent 和人员结合起来，使得复杂的任务可以分配给可重用的团队，而不是单个执行者。
这开始看起来不像是“AI 自动补全”，而更像是一个具备专业能力的开发团队。
例如：
功能需求
↓
规划
↓
实现 Agent
↓
测试 Agent
↓
审查
↓
文档 Agent
↓
人工批准
人类不一定需要手动编排每一次转换。
重要的是工作保持连贯。
Agent 不是项目经理
我认为还有另一个重要的区别。
AI 代理执行任务并不意味着该代理应该成为整个项目的管理者。
人类仍然负责决定：
- 应该构建什么？
- 我们为什么要构建它？
- 哪些约束很重要？
- 应该优先处理什么？
- 什么是可以接受的？
- 工作何时准备好发布？
代理可以执行。
项目管理层可以进行协调。
人类可以做出重要决策。
这种分离实际上是我认为基于代理的项目管理有道理的原因之一。
我们并不是试图让 AI 取代团队。
我们的目标是让团队能够与更强大的 AI 系统协作。
实用的人类 + 代理工作流程
假设一个团队想要在其应用程序中添加一种新的支付方式。
我可以想象工作流程的运作方式如下。
1. 创建需求
开发者创建一个任务，描述支付集成及其验收标准。
2. 分配实现
实现任务被分配给合适的编码代理。
3. 代理进行调查
代理检查仓库并确定现有支付架构的工作方式。
4. 代理实现
它进行所需的更改并运行相关的测试。
5. 开发者介入
开发者注意到该实现未考虑现有的移动工作流。
他们将此信息添加到任务中。
6. 代理进行调整
代理收到后续上下文并继续工作。
7. QA 评审
另一个人检查实现并要求增加测试覆盖率。
8. 代理处理后续工作
代理根据新需求运行另一次执行。
9. 人工批准
开发者审查最终结果并决定是否可以合并。
注意发生了什么。
没有一个巨大的提示。
没有完全自主的 AI 过程。
也没有人手动在工具之间复制每一段上下文。
相反，工作是在共享任务中进行的。
这就是我认为最有趣的模型。
将代理工作转化为团队工作
一旦 AI 代理开始处理真实的开发任务，对话就会超越代理本身。
你需要一个地方来保存需求、其周围的上下文、对话、执行历史以及最终结果。否则，工作很容易被绑定到某个人的终端或一个私有的 AI 会话。
这就是 Sharkly.ai 采取有趣方法的地方。
与其把代理会话视为一切的中心，不如把 Task 变成围绕工作的共享工作空间。人们可以提供上下文和决策，而被分配的代理负责执行。
工作流的不同部分各有职责。Agent 定义特定类型工作的处理方式。Computer 提供该工作能够运行的环境。Runtime 负责实际执行。Task 然后将工作带回到团队其他成员可以跟进的共享上下文。
这种分离很有用，因为代理不必为每个任务从头重建。
团队可能拥有一个配置用于后端开发的代理，另一个用于测试，另一个用于文档。每个代理可以有自己的说明、技能、仓库、环境和 Runtime 配置，而单独的 Task 提供完成工作所需的具体需求和上下文。
这创造了一种不同于每次有工作时仅打开另一个 AI 聊天的工作流。
代理变成了可复用的能力。
Task 成为工作的具体内容。
团队中的成员仍然是流程的一部分。
对于尝试使用多个代理的团队来说，这种区分可能变得越来越重要。挑战不仅在于让代理完成任务，而在于确保 它完成的工作能够被团队其他成员理解、审查、重新定向和继续。
当代理卡住时会发生什么？
这是另一个凸显人机协作重要性的地方。
代理仍然可能会卡住。
它们可能会遇到测试失败、凭据缺失、需求不明确、依赖问题，或者需要人类决策的情况。
一个有用的系统不应掩盖这一点。
它应该凸显对人类关注的需求。
在 Sharkly 中，代理可以将 Task 留待人类回复或审查。失败或被阻塞的工作也可以作为收件箱中的待办项出现，负责人可以打开 Task，进行响应、审查结果、重试，或决定是否重新分配工作。
这是工作流的重要组成部分。
自主并不意味着人类会消失。
这意味着人类会将注意力集中在真正需要的地方。
从 AI 助手到 AI 队友的转变
我认为我们即将到达一个点，此时把每个AI开发工具都称为‘助手’已经不那么有用了。
助手传统上是在等待你。
代理可以承担执行明确工作片段的责任。
这创造了一种完全不同的协作模式。
团队最终可能会拥有：
人类开发者
AI编码代理
测试代理
研究代理
文档代理
运维代理
而他们都可能为同一产品做出贡献。
困难的部分不一定在于找到能够编写代码的代理。
已经有很多可行的选择。
困难的部分将是协调所有这些工作。
谁分配了任务？
代理收到了什么上下文？
它改变了什么？
执行过程中发生了什么？
下一个人需要知道什么？
什么需要审查？
接下来应该发生什么？
这些都是项目管理问题。
最终思考
关于AI代理的有趣问题不仅仅是它们是否能写更多代码。
而是我们的开发工作流程是否已经准备好让它们成为工作的实际参与者。
如果一个代理能够调查问题、修改仓库、运行测试，并在多个步骤中继续工作，那么把它当作简单的聊天机器人开始感觉受限。
更好的模式是协作。
一个人定义目标。
一个代理执行。
另一个人添加上下文。
代理进行适应。
审查者检查结果。
另一个代理可以接手下一阶段。
团队仍然与整个过程保持连接。
这就是我认为代理的项目管理将成为自身重要类别的原因。
目标不是让人类远离软件开发。
而是创建一种工作流程，在这种工作流程中，人类和代理可以在同一问题上协作，而不会在责任转移时丢失上下文。
AI现在可以完成更多的工作。
接下来的挑战是弄清楚我们如何在它工作时共同合作。
