你要做一个微信公众号内容工作流：收集选题、整理资料、生成初稿、人工审核，最后发布。
过去，你可能会打开低代码平台，把这些步骤拖成一条流程。现在，你也可能把目标交给 AI 智能体，让它查资料、调用工具、修改稿件，再根据反馈继续工作。
问题不是“低代码过时了吗”，而是：当任务不再能预先写成固定步骤，我们该怎样组织人、工具与 AI？
低代码：让更多人能够搭建流程
低代码是一种尽量减少手写代码的软件开发方式。它通常通过可视化建模、拖放组件和点击式界面，帮助用户创建应用与业务流程。对需求明确、步骤稳定的工作，它能降低开发门槛，也能让业务人员更直接地参与搭建。
比如，一份表单提交后通知编辑，编辑审核通过后更新状态。这类流程的入口、节点和分支都相对清楚，低代码工具很合适。
但如果任务变成“围绕一个新话题，找到可靠资料，判断哪些观点值得写，并根据审稿意见反复修改”，难点就不只是连接几个节点。资料可能互相矛盾，审稿意见也无法事先穷举。
Agent Harness：设计 AI 工作的环境
Agent Harness 可以理解为围绕模型的一套运行与控制机制。 模型负责理解和生成；Harness 则负责组织上下文、连接工具、保存任务状态、控制权限，并把执行结果反馈给模型。它让 AI 不止回答一次问题，而是能够在有边界的环境里完成多步骤任务。
放到写作场景中，Harness 不是一句“写篇文章”的提示词，而是整套工作安排：
- 给出选题目标、读者画像和写作规范；
- 限定可用资料，并记录来源；
- 允许调用检索、编辑等工具，但对发布操作设置人工确认；
- 保存草稿与修改记录，用事实核对和审稿意见推动下一轮修改。
这里有一个关键区别：能调用工具，不等于可以不受约束地调用工具。 一个可靠的智能体工作流，需要明确哪些事可自动执行，哪些事必须由人批准；还需要让错误可发现、过程可追溯。Harness 的价值，正是在模型能力之外，把这些运行条件组织起来。
从“搭流程”转向“定目标、划边界”
低代码思维习惯先问：“流程有几个节点？每个节点连向哪里？”面对开放式任务，可以换一种问法：
| 先问什么 |
再设计什么 |
| 要达成什么结果？ |
定义交付物与完成标准 |
| AI 能依据什么行动？ |
提供资料、工具和必要上下文 |
| 哪些错误不能接受？ |
设置权限、审核点与停止条件 |
| 如何判断它做对了？ |
核对来源、检查产物、接收反馈 |
这不是把流程图换成一段更长的提示词。提示词可以指导模型，但稳定的执行还依赖工具权限、状态管理、反馈与评估。
也不必把低代码和智能体对立起来。固定、可预测的环节可以继续交给低代码；需要检索、判断和迭代的环节，可以引入智能体。 两者的分工，应由任务本身决定。
结果导向：不要用“自动化程度”代替“完成质量”
一个流程跑通了，不代表文章可以发表。智能体生成了初稿，也不代表事实准确、观点清晰，更不代表符合读者需要。
因此，在选择工具前，先写下可检验的结果：文章是否回应了选题？关键说法是否有来源？读者能否看懂并获得可执行的认识？发布前是否有人对事实和表达负责？
当这些标准明确后，技术选择反而简单了：该用表单的地方用表单，该让 AI 处理复杂信息的地方让 AI 参与，该由人判断的地方保留人的判断。
AI 时代真正需要转变的，不是从一个工具迁移到另一个工具，而是从“我搭好了什么流程”，转向“我们可靠地完成了什么”。 这也是云栈社区持续讨论的命题：在模型能力快速变动的当下，如何把工具、流程与人的判断重新组织起来。
参考资料
- Microsoft Power Apps：什么是低代码？低代码平台指南
- Wikipedia：Agent harness
- Medium：Agentic Harnesses: The New Infrastructure Layer for AI Systems?
| 
发表于 半小时前
|
查看: 4|
回复: 0
